RE: LATEST / RELEASE dependency version
I recently had a write-up on this (more of a reminder to myself) http://www.blogwitter.com/2009/07/20/maven-plugin-notes/ Thanks, mohan kr -Original Message- From: james.sh...@nomura.com [mailto:james.sh...@nomura.com] Sent: Wednesday, September 23, 2009 5:24 AM To: users@maven.apache.org Subject: RE: LATEST / RELEASE dependency version Thanks Stephen, that's very helpful - hadn't appreciated the subtle difference that LATEST was not necessarily LARGEST. Will take a good look at ranges then - thanks -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 22 September 2009 20:31 To: Maven Users List Cc: users@maven.apache.org Subject: Re: LATEST / RELEASE dependency version these are *deprecated* features they never do what you think they do! LATEST picks the last version to be deployed... RELEASE picks the last non-SNAPSHOT to be deployed now imagine you have two development streams in progress... 1.x and 2.x as each stream deploys their releases, RELEASE will jump back and forth between the two versions... 1.1, 2.1, 1.2, 1.3, 2.2, 1.4, 2.3, 1.1.1, etc not what you want... LATEST plays the same way, only with -SNAPSHOTs added into the mix, so now your CI server redeploying the latest -SNAPSHOTs after each commit makes everyone scream usually what you want is version ranges, or (plug) use versions-maven- plugin to update versions for you in a mire controlled manor than version ranges allow (the issue with version ranges is you cannot exclude an intermediate - SNAPSHOT from creaping in to any range... but then sometimes, ie during development, that is exactly what you want!) Sent from my [rhymes with tryPod] ;-) On 22 Sep 2009, at 20:03, james.sh...@nomura.com wrote: Looking in the Sonatype Maven book I see mention of the ability to specify the version of a dependency as LATEST or RELEASE (http://www.sonatype.com/books/maven-book/reference/pom-relationships-se ct-pom-syntax.html , 9.3.1.3) However when I try this (I'm using 2.0.9 and Nexus) it doesn't seem to work and just tries looking for a version with the explicit name LATEST rather than using the repo's metadata. I don't see the concept of LATEST or RELEASE mentioned anywhere in the official Maven docs though (http://maven.apache.org/guides/introduction/introduction-to-dependency- mechanism.html) Is this functionality actually in 2.0.9 or was it dropped (or indeed added in a later version)? Afraid the FAQs and Google aren't turning up any conclusive information either way Thanks James This e-mail (including any attachments) is confidential, may contain proprietary or privileged information and is intended for the named recipient(s) only. Unintended recipients are prohibited from taking action on the basis of information in this e-mail and must delete all copies. Nomura will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in, this e-mail. If verification is sought please request a hard copy. Any reference to the terms of executed transactions should be treated as preliminary only and subject to formal written confirmation by Nomura. Nomura reserves the right to monitor e-mail communications through its networks (in accordance with applicable laws). No confidentiality or privilege is waived or lost by Nomura by any mistransmission of this e-mail. Any reference to Nomura is a reference to any entity in the Nomura Holdings, Inc. group. Please read our Electronic Communications Legal Notice which forms part of this e-mail: http://www.Nomura.com/email_disclaimer.htm - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This e-mail (including any attachments) is confidential, may contain proprietary or privileged information and is intended for the named recipient(s) only. Unintended recipients are prohibited from taking action on the basis of information in this e-mail and must delete all copies. Nomura will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in, this e-mail. If verification is sought please request a hard copy. Any reference to the terms of executed transactions should be treated as preliminary only and subject to formal written confirmation by Nomura. Nomura reserves the right to monitor e-mail communications through its networks (in accordance with applicable laws). No confidentiality or privilege is waived or lost by Nomura by any mistransmission of this e-mail. Any reference to Nomura is a reference to any entity in the Nomura Holdings, Inc. group. Please read our Electronic Communications Legal Notice which forms part of this e-mail: http://www.Nomura.com/email_disclaimer.htm
Potential regression with maven-javadoc-plugin 2.6
I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the links configured in my plugin config. Now all resolution of external links fail (we are behind a proxy *not* NTLM) with this: Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: ntlm authentication scheme selected Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector authenticate The wagon provider appears to have been upgraded to 1.0-beta-6 in the maven-javadoc-plugin 2.6 (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is wrong) that wagon 1.0-beta-6 requires Maven 2.1.x and above? If that is the case, I don't understand how the plugin was released with prerequisite of 2.0.9? Is there a workaround to disable the default ntlm auth scheme via a magical system property? TIA Thanks, mohan kr
RE: Why is maven looking for snapshot plugins ?
Can you paste the surrounding context around the log message or attach the whole log? Some plugins still go outside (is the log from the project-info plugin by any chance?) Thanks, mohan kr -Original Message- From: JeremieB [mailto:jeremie.bousq...@gmail.com] Sent: Friday, August 07, 2009 7:58 AM To: users@maven.apache.org Subject: RE: Why is maven looking for snapshot plugins ? Sorry if I did not precise it exhaustively, but in fact taglist 2.3 is declared in pluginManagement, in plugins, in dependencies, in dependencyManagement and in reporting sections as well... (in the corporate pom). maven-site-plugin is declared only in pluginManagement section. I also deleted anything about this snapshot version of taglist (metadata and jar) from my archiva managed repositories, with no change. What I don't understand is this log : [DEBUG] taglist-maven-plugin: resolved to version 2.4-SNAPSHOT from repository central ...because this version is NOT in central repository... I really miss some understanding on maven plugins way of working I'm afraid :( I understand it's retrieving youngest version, but it should not as I declared a specific version ? mkr wrote: You have to specify the version of the plugin in the reporting/plugins *also*, it is not enough to put the version in the pluginManagement or build/plugins section. The other thing is I believe for plugins Maven is going to retrieve the youngest version (regardless of SNAPSHOT or RELEASE). cheers -- View this message in context: http://www.nabble.com/Why-is-maven-looking-for-snapshot-plugins---tp24840838 p24864407.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Why is maven looking for snapshot plugins ?
This has been answered a few times already. You have to specify the version of the plugin in the reporting/plugins *also*, it is not enough to put the version in the pluginManagement or build/plugins section. The other thing is I believe for plugins Maven is going to retrieve the youngest version (regardless of SNAPSHOT or RELEASE). cheers Thanks, mohan kr -Original Message- From: JeremieB [mailto:jeremie.bousq...@gmail.com] Sent: Thursday, August 06, 2009 6:33 AM To: users@maven.apache.org Subject: Re: Why is maven looking for snapshot plugins ? I think my request is not very clear, this is what I did more clearly (I hope so) : 1- add a managed repository for staged-releases in archiva, proxy of central snapshots 2- add this repository in my repository group 3- declare my repository group as a pluginRepository in my corporate pom 4- change version of maven-site-plugin from 2.0-beta-7 to 2.1-SNAPSHOT in corporate pom 5- install corporate pom 6- run site-deploy on a child of corporate pom -- ok 7- removed proxy connector from my staged-releases repository (to avoid non wanted plugins to be downloaded) 8- re-run step 6 to check -- still ok 9- deleted my local repository 10- re-run step 6 -- fails and complains about taglist-maven-plugin not finding 2.4-SNAPSHOT version, while 2.3 is specified eveywhere -- View this message in context: http://www.nabble.com/Why-is-maven-looking-for-snapshot-plugins---tp24840838 p24844830.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Prevent Install of Assembly
set the attachfalse/attach in the plugin config. Thanks, mohan kr -Original Message- From: Jim Collings [mailto:jlistn...@gmail.com] Sent: Friday, July 24, 2009 9:52 AM To: Maven Users List Subject: Re: Prevent Install of Assembly Yes. I've been reading this page. Can you be more specific? On Thu, Jul 23, 2009 at 11:50 AM, Nord, Jamesjn...@nds.com wrote: http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attac h -Original Message- From: Jim Collings [mailto:jlistn...@gmail.com] Sent: 23 July 2009 16:43 To: Maven Users List Subject: Re: Prevent Install of Assembly Didn't work. Neither did changing appendAssemblyId to false. Anybody have additional ideas? On Thu, Jul 23, 2009 at 11:25 AM, Jim Collingsjlistn...@gmail.com wrote: http://maven.apache.org/plugins/maven-assembly-plugin/usage.html So the docs I found at the link above had this to say: When the assembly is created it will use the assemblyId as the artifact's classifier and will attach the created assembly to the project and will be uploaded into the repository on an install and deploy goal.' So in theory all I have to do is change the assemblyId? I'll see if I can figure out how to do this and try a test. On Thu, Jul 23, 2009 at 11:18 AM, Jim Collingsjlistn...@gmail.com wrote: So I have a sub module that has an assembly. It is associated with the package goal. Each time I run install though, the zip file created is placed in the repository. There is no need for this. How can I prevent it? Jim C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ** - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Putting instrumented classes on the classpath
You have to give more information? I have looked at the thread..but if you were using the cobertura-maven-plugin and just have the intstrument goal, it *WILL* put the instrumented classes in the classpath. (i.e. classes/* will be redirected to generated-classes/*). Since plugin ordering varies between maven versions (if binding to same phase), I would make sure that the cobertura instrument goal is last executed in that phase. Also, I think I replied yesterday, if you need the coverage xml file, then the standard cobertura plugin cannot do that *independently*, you can use the modded plugin Thanks, mohan kr -Original Message- From: lvdpal [mailto:lvd...@lunaris-informatica.nl] Sent: Wednesday, July 22, 2009 4:23 AM To: users@maven.apache.org Subject: RE: Putting instrumented classes on the classpath Because I'm still looking for a solution to this prolem. It's such a shame to use Sonar when having tests and not getting any code coverage. lvdpal wrote: Nobody else has any ideas? -- View this message in context: http://www.nabble.com/Putting-instrumented-classes-on-the-classpath-tp241836 79p24602797.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Putting instrumented classes on the classpath
np..I will have to reword that, it will redirect the project.build.outputDirectory from target/classes to target/generated-classes/cobertura. If the plugins are doing the correct thing when constructing the classpath, they should use the property project.build.outputDirectory. Thanks, mohan kr -Original Message- From: lvdpal [mailto:lvd...@lunaris-informatica.nl] Sent: Wednesday, July 22, 2009 8:25 AM To: users@maven.apache.org Subject: RE: Putting instrumented classes on the classpath Thanks, this at least gives me a hint where to start looking. mkr wrote: You have to give more information? I have looked at the thread..but if you were using the cobertura-maven-plugin and just have the intstrument goal, it *WILL* put the instrumented classes in the classpath. (i.e. classes/* will be redirected to generated-classes/*). Since plugin ordering varies between maven versions (if binding to same phase), I would make sure that the cobertura instrument goal is last executed in that phase. Also, I think I replied yesterday, if you need the coverage xml file, then the standard cobertura plugin cannot do that *independently*, you can use the modded plugin Thanks, mohan kr -- View this message in context: http://www.nabble.com/Putting-instrumented-classes-on-the-classpath-tp241836 79p24606483.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Surefire/Cobertura roll-up reports?
That's correct, depending on how you are invoking the cobertura, you will see that. Basically the cobertura goal is going to invoke a parallel lifecycle that will run the test. It is easy to modify the plugin to do what you want, if you don't then someone has done it for you: http://top.touk.pl/maven2/release/org/codehaus/mojo/cobertura-maven-plugin/2.2-touk That's a m2 repo. It has one additional goal generate-report that will *not* fork a lifecycle, so you won't have the hudson double or treble vision. (There is no doc. on the plugin, but basically you clean,instrument, generate-report in different phases of your regular build). Thanks, mohan kr -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Monday, July 20, 2009 8:51 PM To: Maven Users List Subject: Re: Surefire/Cobertura roll-up reports? Adam Purkiss wrote: As for surefire - no idea, but using Hudson as our CI tool I have it setup to roll up the Junit results to a top level using its reporting. We use Hudson, as well, but we've noticed that between Surefire and Cobertura, we end up with two or three copies of each test result. So, it appears like we have 2 to 3 times more unit tests than we really do. I guess it depends on what Hudson is rolling up. Perhaps I'm using the plugins in a way that I should not be. I'm trying to satisfy both the needs of the development team in getting code built and deployed to a test server (where we then come back and run some automated integration tests through Maven with Selenium) and the desires of management who really love to look at the pretty reports. :-) It was actually this discrepancy in the Hudson rollup that prompted my question in the first place. Otherwise, that's a great suggestion. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: site.xml for parent/child site which are siblings
I have been using menu ref, even as recently as two days ago in one of the multi-module project. Which version of site-plugin are you using? I'm using 2.0-beta-7. Do all the sibling modules have a site descriptor, with menu ref=parent? The breadcrumbs could be a problem in the default skin. I don't use the default skin, if you know velocity, you can download the default skin and peer into where things might be going wrong. (BTW, you can change the skin in site.xml) Thanks, mohan kr -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Tuesday, July 14, 2009 6:57 PM To: Maven Users List Subject: Re: site.xml for parent/child site which are siblings I would really like to know if you're using the menu ref=parent/ and if it works?? I've been playing with it for the better part of two days, and I cannot get the parent link to show up at all. I've also been playing with breadcrumbs, but they appear to be severely broken - or, I just don't understand what they're supposed to be used for. :-) jaybytez wrote: Looks like it works if use the following at the command line: $ mvn site:stage -DstagingDirectory=c:/beaportal/user_projects/workspaces/default/avitek/published-site/site Is it best to build a site to a staging area and then push that staging area to a remote server? It appears to correctly have created the site with no modifications to POMs. My only outstanding question now is, the menu ref=parent is not working for me in the child poms...any reason for this? Thanks - jay jaybytez wrote: I have the following structure for my app: avitek -avitekApp (EAR) - pom.xml -avitekParent - src/site/site.xml - pom.xml -avitekWeb (WAR) - pom.xml My parent pom.xml in avitekParent says the following: [code] modelVersion4.0.0/modelVersion groupIdavitek-sample/groupId artifactIdparent/artifactId packagingpom/packaging version1.0-SNAPSHOT/version nameMaven 2 Portal Sample/name modules module../avitekApp/module module../avitekWeb/module /modules [/code] Then my site.xml for the parent (avitekParent) says this: [code] menu ref=modules name=Components/ [/code] So when I open: C:\beaportal\user_projects\workspaces\default\avitek\avitekParent\target\site\index.html It gives me links to my child projects (modules), but the urls that get generated into the html are like this: C:\beaportal\user_projects\workspaces\default\avitek\avitekParent\target\site\avitekWeb\index.html And they need to look like: C:\beaportal\user_projects\workspaces\default\avitek\avitekWeb\target\site\index.html Any thoughts or suggestions? Thanks...jay - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: hudson + build-number-plugin can't find svn
I don't have access to the project right now. I remember it is the incompatibility with the svn versions. IIRC Hudson built-in (svn kit) uses 1.5, so when it checks out the sources the metadata is 1.5 compatible. So if your /usr/local/svn is 1.4 then you will get the error. Thanks, mohan kr -Original Message- From: Lachlan Deck [mailto:lachlan.d...@gmail.com] Sent: Wednesday, July 15, 2009 8:02 PM To: Maven Users List Subject: hudson + build-number-plugin can't find svn Hi there, We've set up hudson on our build server but are invariably finding that it fails to find the svn executable when building (see below stack trace). We've defined in hudson the environment variable 'svn' as /usr/local/ bin/svn. However this doesn't seem to be working (or not always). Does anyone know of a surefire way of setting this up so that svn is found on the path? Thanks. [INFO] Cannot get the revision information from the scm repository : Exception while executing SCM command. java.io.IOException: error=2, No such file or directory [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Cannot get the revision information from the scm repository : Exception while executing SCM command. at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 703) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeTaskSegments(DefaultLifecycleExecutor.java:332) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org .apache .maven .lifecycle .LifecycleExecutorInterceptor .execute(LifecycleExecutorInterceptor.java:65) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at hudson.maven.agent.Main.launch(Main.java:165) at hudson.maven.MavenBuilder.call(MavenBuilder.java:159) at hudson.maven.MavenModuleSetBuild $Builder.call(MavenModuleSetBuild.java:601) at hudson.maven.MavenModuleSetBuild $Builder.call(MavenModuleSetBuild.java:547) at hudson.remoting.UserRequest.perform(UserRequest.java:103) at hudson.remoting.UserRequest.perform(UserRequest.java:47) at hudson.remoting.Request$2.run(Request.java:236) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java: 441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor $Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor $Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot get the revision information from the scm repository : Exception while executing SCM command. at org.codehaus.mojo.build.BuildMojo.getRevision(BuildMojo.java:502) at org.codehaus.mojo.build.BuildMojo.execute(BuildMojo.java:377) at org .apache .maven .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at hudson .maven .agent .PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 678) ... 28 more Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command. at org .apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java: 59) at org.codehaus.mojo.build.BuildMojo.info(BuildMojo.java:526) at org.codehaus.mojo.build.BuildMojo.getRevision(BuildMojo.java:494) ... 32 more Caused by: org.apache.maven.scm.ScmException: Error while executing command. at org .codehaus
RE: hudson + build-number-plugin can't find svn
you need to downgrade to 1.5.x to match hudsons version. I just installed 1.5.x client on the Hudson box...you basically have to match the Hudson internal svn version. Thanks, mohan kr -Original Message- From: Lachlan Deck [mailto:lachlan.d...@gmail.com] Sent: Wednesday, July 15, 2009 9:54 PM To: Maven Users List Subject: Re: hudson + build-number-plugin can't find svn On 16/07/2009, at 12:21 PM, Mohan KR wrote: I don't have access to the project right now. I remember it is the incompatibility with the svn versions. IIRC Hudson built-in (svn kit) uses 1.5, so when it checks out the sources the metadata is 1.5 compatible. So if your /usr/local/svn is 1.4 then you will get the error. Interesting. Makes sense. Our /usr/local/bin/svn is 1.6.3 though. Any suggestions on what to do? Thanks Thanks, mohan kr -Original Message- From: Lachlan Deck [mailto:lachlan.d...@gmail.com] Sent: Wednesday, July 15, 2009 8:02 PM To: Maven Users List Subject: hudson + build-number-plugin can't find svn Hi there, We've set up hudson on our build server but are invariably finding that it fails to find the svn executable when building (see below stack trace). We've defined in hudson the environment variable 'svn' as /usr/local/ bin/svn. However this doesn't seem to be working (or not always). Does anyone know of a surefire way of setting this up so that svn is found on the path? Thanks. [INFO] Cannot get the revision information from the scm repository : Exception while executing SCM command. java.io.IOException: error=2, No such file or directory [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Cannot get the revision information from the scm repository : Exception while executing SCM command. at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 703) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java: 519) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeTaskSegments(DefaultLifecycleExecutor.java:332) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org .apache .maven .lifecycle .LifecycleExecutorInterceptor .execute(LifecycleExecutorInterceptor.java:65) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at hudson.maven.agent.Main.launch(Main.java:165) at hudson.maven.MavenBuilder.call(MavenBuilder.java:159) at hudson.maven.MavenModuleSetBuild $Builder.call(MavenModuleSetBuild.java:601) at hudson.maven.MavenModuleSetBuild $Builder.call(MavenModuleSetBuild.java:547) at hudson.remoting.UserRequest.perform(UserRequest.java:103) at hudson.remoting.UserRequest.perform(UserRequest.java:47) at hudson.remoting.Request$2.run(Request.java:236) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java: 441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor $Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor $Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot get the revision information from the scm repository : Exception while executing SCM command. at org.codehaus.mojo.build.BuildMojo.getRevision(BuildMojo.java:502) at org.codehaus.mojo.build.BuildMojo.execute(BuildMojo.java:377) at org .apache .maven .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java: 483) at hudson .maven .agent .PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java: 182) at org .apache .maven .lifecycle
RE: hudson + build-number-plugin can't find svn
Sorry, I'm looking at the stack trace, it appears the svn executable is not found. How are you launching Hudson? Make sure the startup script that launches Hudson has /usr/local/bin in its PATH. Thanks, mohan kr -Original Message- From: Lachlan Deck [mailto:lachlan.d...@gmail.com] Sent: Wednesday, July 15, 2009 9:54 PM To: Maven Users List Subject: Re: hudson + build-number-plugin can't find svn On 16/07/2009, at 12:21 PM, Mohan KR wrote: I don't have access to the project right now. I remember it is the incompatibility with the svn versions. IIRC Hudson built-in (svn kit) uses 1.5, so when it checks out the sources the metadata is 1.5 compatible. So if your /usr/local/svn is 1.4 then you will get the error. Interesting. Makes sense. Our /usr/local/bin/svn is 1.6.3 though. Any suggestions on what to do? Thanks Thanks, mohan kr -Original Message- From: Lachlan Deck [mailto:lachlan.d...@gmail.com] Sent: Wednesday, July 15, 2009 8:02 PM To: Maven Users List Subject: hudson + build-number-plugin can't find svn Hi there, We've set up hudson on our build server but are invariably finding that it fails to find the svn executable when building (see below stack trace). We've defined in hudson the environment variable 'svn' as /usr/local/ bin/svn. However this doesn't seem to be working (or not always). Does anyone know of a surefire way of setting this up so that svn is found on the path? Thanks. [INFO] Cannot get the revision information from the scm repository : Exception while executing SCM command. java.io.IOException: error=2, No such file or directory [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Cannot get the revision information from the scm repository : Exception while executing SCM command. at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 703) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java: 519) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeTaskSegments(DefaultLifecycleExecutor.java:332) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org .apache .maven .lifecycle .LifecycleExecutorInterceptor .execute(LifecycleExecutorInterceptor.java:65) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at hudson.maven.agent.Main.launch(Main.java:165) at hudson.maven.MavenBuilder.call(MavenBuilder.java:159) at hudson.maven.MavenModuleSetBuild $Builder.call(MavenModuleSetBuild.java:601) at hudson.maven.MavenModuleSetBuild $Builder.call(MavenModuleSetBuild.java:547) at hudson.remoting.UserRequest.perform(UserRequest.java:103) at hudson.remoting.UserRequest.perform(UserRequest.java:47) at hudson.remoting.Request$2.run(Request.java:236) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java: 441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor $Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor $Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot get the revision information from the scm repository : Exception while executing SCM command. at org.codehaus.mojo.build.BuildMojo.getRevision(BuildMojo.java:502) at org.codehaus.mojo.build.BuildMojo.execute(BuildMojo.java:377) at org .apache .maven .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java: 483) at hudson .maven .agent .PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java: 182) at org .apache .maven .lifecycle
RE: Examples of multi-module site generation?
Do you have the following element in your child modules site.xml? menu ref=parent / Thanks, mohan kr -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Sunday, July 12, 2009 9:54 PM To: Maven Users Subject: Examples of multi-module site generation? Can anyone point me to anything that actually works? I've tried every example I can find via Google (what few there are), and I cannot get the modules to generate a link back to the parent project. Breadcrumbs don't seem to behave, either. Maybe I'm an oddball and the only person who doesn't know the absolute URL where my pages will reside, but I would think that relative URLs would work. Any help? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven spring eclipse and properties/spring config
Yup, that is a decision you have to make. But in general, the approach I
have been using is
this:
- You spring-context files rarely should be different for each environment
(if you think hard enough, you
can achieve it :)).
- We externalize all environment specific information from Spring Context
files as properties and use
Spring PPC (property placeholder) to substitute the relevant values during
the Bean Factory lifecycle.
- You can do all the resource filtering (maven) on *those* properties files
above that are externalized.
It will take a very long message or an article to show an example :), but
information above should get
you going, I hope.
Thanks,
mohan kr
-Original Message-
From: Tim O'Brien [mailto:tobr...@discursive.com]
Sent: Saturday, July 11, 2009 11:03 AM
To: Maven Users List
Subject: Re: maven spring eclipse and properties/spring config
On Fri, Jul 10, 2009 at 1:54 PM, Vincent Fumoneo...@gmail.com wrote:
I'm converting an old project to maven and I have a question re: spring.
This project has about 20 spring config files and it reads them all in on
startup and uses the In addition I have 4 properties files
(local/dev/qa/prod) that I'd like to use to inject/filter/substitute
values
into them depending on the build. Lastly I am using the eclipse plugin to
generate an eclipse project.
What I need to know is the following :
1) where should I put the spring files? I am considering
src/main/resources/spring
If you load them from the classpath, put them in src/main/resources.
By default everything in this directory will end up in target/classes
(if your project uses a packaging of jar)
2) how should I best filter the props files? Should I use maven for this
(using profiles in some way), or should I load the files in the app and
use
the spring properties configurator?
I don't think anyone on this list is qualified to make this
architectural decision for you. But, if you wanted to use Maven
Resource filtering, you could. You would have a single properties
file: whatever.properties which would contain references to arbitrary
properties such as ${whatever.jdbc.url}, then you would use profiles
and configure resource filtering on this properties file.
3) what is the best way to use the eclipse plugin to generate a project
where I can run the app and it can see the newly filtered spring files
(instead of the src ones)?
m2eclipse is going to automatically call process-resources
resources:testResources every time you change a resource and copy the
result to target/classes. You can control the profile via your
project's Maven preferences in m2eclipse.
Can anyone help me out? I'd certainly give more info if needed.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency Report searching outside repositories?
I believe this is a problem, don't know whether it has been fixed. But I'm able to get around this by setting the plugin configuration dependencyLocationsEnabled to false and dependencyDetailsEnabled to false Thanks, mohan kr -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Saturday, July 11, 2009 2:56 PM To: Maven Users Subject: Dependency Report searching outside repositories? It looks to me like the Dependencies report, created during site generation, is searching external repositories to find the information it needs. But, it seems like that information should already be in my local repository, assuming that the code had to be built before we can generate the site. It takes me about 12 minutes to build a site for which the entire project will build in about 45 seconds. Am I understanding this appropriately? Or, is there maybe some kind of defect that needs to be looked into? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Using UmlGraphDoc with Maven
I have using both UMLGraph and Apiviz, at least with APIViz you don't need to 'install' the UMLgraph, it is available from jboss repo. Of course, both of them require the dot.exe to be available in the classpath. http://code.google.com/p/apiviz/ Thanks, mohan kr -Original Message- From: Jeff Mutonho [mailto:ejbeng...@gmail.com] Sent: Thursday, July 09, 2009 2:00 AM To: Maven Users List Subject: Re: Using UmlGraphDoc with Maven Thanks Paul , but I still seem out of luck. I downloaded UmlGraph version 4.8 and installed it as mvn install:install-file -Dpackaging=jar -DartifactId=UmlGraph -Dversion=4.8 -Dfile=C:/devenv/UMLGraph-4.8/lib/UmlGraph.jar -DgroupId=gr.spinellis -DgeneratePom=true then reconfigured the javadoc plugin to match the working example : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration aggregatetrue/aggregate docletgr.spinellis.umlgraph.doclet.UmlGraphDoc/doclet docletArtifact groupIdgr.spinellis/groupId artifactIdUmlGraph/artifactId version4.8/version /docletArtifact additionalparam -inferrel -inferdep -quiet -hide java.* -collpackages java.util.* -qualify -postfixpackage -nodefontsize 9 -nodefontpackagesize 7 /additionalparam /configuration /plugin I still am not getting any .dot generated. I noticed the following in from my mvn -X javadoc:javadoc output : [DEBUG] (f) docletArtifact = groupId = 'null' artifactId = 'null' version = 'null' [DEBUG] (f) docletArtifacts = [] Does this mean maven-javadoc-plugin isn't recognizing the UmlGraphDoc doclet? Or is that output normal? On Thu, Jul 9, 2009 at 7:50 AM, Paul Benedict pbened...@apache.org wrote: Here is a real working example: http://svn.apache.org/viewvc/tiles/framework/trunk/pom.xml?revision=790631c ontent-type=text%2Fplain Paul On Thu, Jul 9, 2009 at 12:44 AM, Jeff Mutonhoejbeng...@gmail.com wrote: Hi After reading the article on this DZone article - Reverse Engineer Source Code http://java.dzone.com/articles/reverse-engineer-source-code-u I configured my pom as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration aggregatetrue/aggregate docletorg.umlgraph.doclet.UmlGraphDoc/doclet docletArtifact groupIdorg.umlgraph/groupId artifactIdumlGraph/artifactId version5.0/version /docletArtifact additionalparam -inferrel -inferdep -quiet -hide java.* -collpackages java.util.* -qualify -postfixpackage -nodefontsize 9 -nodefontpackagesize 7 /additionalparam destDirtarget/uml/destDir showprivate/show /configuration /plugin I installed Graphviz and C:\Graphviz2.24\bin is in my PATH. However when I run mvn javadoc:javadoc or even better still mvn site:deploy , there aren't any UML image files(i.e .dot) files being generated. Any clues on how I can get this to work? Thanx -- Don't take the name of root in vain. Jeff Mutonho Cape Town South Africa GoogleTalk : ejbengine Skype: ejbengine Registered Linux user number 366042 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Don't take the name of root in vain. Jeff Mutonho Cape Town South Africa GoogleTalk : ejbengine Skype: ejbengine Registered Linux user number 366042 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Reporting Plugins Not Inheriting Versions
Yup..got bitten by it..As a best practice you have to lock down the plugin version in the reporting section, it is *not* propogated from the pluginManagement I believe. (at least not in 2.0.9), I believe there is a JIRA issue to have a reportingManagement section or supposed to be fixed in 3.0.x :) Thanks, mohan kr -Original Message- From: Jeff Storey [mailto:jeff.sto...@nextcentury.com] Sent: Thursday, July 09, 2009 9:21 AM To: users@maven.apache.org Subject: Reporting Plugins Not Inheriting Versions Hi, I have a few reporting plugins defined in the reporting section of my POM. According to http://docs.codehaus.org/display/MAVENUSER/Reporting+Plugins, when I invoke the goals from the command line, the configurations from the reporting sections should be used. The configurations are in fact used, but the versions are not. For example, I defined cobertura 2.2 in the reporting section, but when I run mvn cobertura:cobertura, it fetches the latest version (2.3) from the repository. In order to make this work, I need to list the plugin in both the reporting and plugins sections (though I only need to list the configuration in the reporting section). Is there a way to automatically pull the version from the reporting section as well? My current approach is to list it in both places and use a property for the version number. Thanks, Jeff - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: excluding inner classes
I thought by default it is excluded (at least for surefire).. Thanks, mohan kr -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Saturday, July 04, 2009 5:40 PM To: Jeff Bowman; Maven Users List Subject: Re: excluding inner classes It is better to ask questions on the users list as that way the answers are available for everyone 2009/7/3 Jeff Bowman jeff.t.bow...@gmail.com Is there a way to exclude innerclasses from failsafe/surefire? For my integration tests, I'm getting a lot of failures on helper classes which I've coded as inner classes in the integration tests (like RowMappers, etc). Thanks, Jeff -- Amateurs work until they get it right... ... Professionals work until they can't get it wrong. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: surefire and spring - Autowiring of methods failed
What do you mean by But when I try to run the surefire plugin the autowire
did not work. and mvn test works?
Doesn't mvn test invoke the surefire plugin?
(Also, you can autowire directly on the field, instead of the property, save
some code)
Thanks,
mohan kr
-Original Message-
From: Chávez, Carlos [mailto:ccha...@agssa.net]
Sent: Sunday, July 05, 2009 6:34 AM
To: users@maven.apache.org
Subject: surefire and spring - Autowiring of methods failed
Hello everyone.
I configured the test cases to use annotations and autowire, everything
works
as expected when i run mvn test or install.
But when I try to run the surefire plugin the autowire did not work.
*
The Following is the dependecy tree:
*
[INFO] [dependency:tree {execution: default-cli}]
[INFO] ni.gob.cgr.siirci:dao:jar:1.0-SNAPSHOT
[INFO] +- ni.gob.cgr.siirci:bean:jar:1.0-SNAPSHOT:compile
[INFO] | \- commons-lang:commons-lang:jar:2.4:compile
[INFO] +- ni.gob.cgr.siirci:hibernate:jar:1.0-SNAPSHOT:compile
[INFO] | +- org.hibernate:hibernate-annotations:jar:3.4.0.GA:compile
[INFO] | | +- org.hibernate:ejb3-persistence:jar:1.0.2.GA:compile
[INFO] | | +- org.hibernate:hibernate-core:jar:3.3.0.SP1:compile
[INFO] | | | +- antlr:antlr:jar:2.7.6:compile
[INFO] | | | \- javax.transaction:jta:jar:1.1:compile
[INFO] | | \- dom4j:dom4j:jar:1.6.1:compile
[INFO] | +-
org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga:compile
[INFO] | | \- org.hibernate:hibernate:jar:3.2.1.ga:compile
[INFO] | | +- asm:asm-attrs:jar:1.5.3:compile
[INFO] | | +- cglib:cglib:jar:2.1_3:compile
[INFO] | | \- asm:asm:jar:1.5.3:compile
[INFO] | +- org.slf4j:slf4j-nop:jar:1.5.8:compile
[INFO] | +- org.slf4j:slf4j-api:jar:1.5.8:compile
[INFO] | +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] | \- javassist:javassist:jar:3.8.0.GA:compile
[INFO] +- postgresql:postgresql:jar:8.3-604.jdbc3:compile
[INFO] +- org.springframework:spring:jar:2.5.6.SEC01:compile
[INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] +- org.springframework:spring-hibernate3:jar:2.0.8:compile
[INFO] | +- aopalliance:aopalliance:jar:1.0:compile
[INFO] | +- org.springframework:spring-beans:jar:2.0.8:compile
[INFO] | +- org.springframework:spring-context:jar:2.0.8:compile
[INFO] | +- org.springframework:spring-core:jar:2.0.8:compile
[INFO] | +- org.springframework:spring-dao:jar:2.0.8:compile
[INFO] | \- org.springframework:spring-jdbc:jar:2.0.8:compile
[INFO] +- commons-dbcp:commons-dbcp:jar:1.2.2:compile
[INFO] | \- commons-pool:commons-pool:jar:1.3:compile
[INFO] +- junit:junit:jar:4.6:test
[INFO] \- org.springframework:spring-test:jar:2.5.6.SEC01:test
*
The following is the stacktrace:
*
[INFO] skip non existing resourceDirectory
/home/cchavez/workspace/siirci/dao/src/test/resources
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/cchavez/workspace/siirci/dao/target/surefire-reports
07-05-2009 04:56:55 AM org.springframework.test.context.TestContextManager
retrieveTestExecutionListeners
INFO: @TestExecutionListeners is not present for class [class
ni.gob.cgr.siirci.facade.UsuarioFacadeTestCase]: using defaults.
---
T E S T S
---
Running ni.gob.cgr.siirci.facade.UsuarioFacadeTestCase
07-05-2009 04:56:55 AM
org.springframework.beans.factory.xml.XmlBeanDefinitionReader
loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource
[applicationContext.xml]
07-05-2009 04:56:56 AM
org.springframework.context.support.AbstractApplicationContext
prepareRefresh
INFO: Refreshing
org.springframework.context.support.genericapplicationcont...@fbb7cb:
display
name [org.springframework.context.support.genericapplicationcont...@fbb7cb];
startup date [Sun Jul 05 04:56:56 CST 2009]; root of context hierarchy
07-05-2009 04:56:56 AM
org.springframework.context.support.AbstractApplicationContext
obtainFreshBeanFactory
INFO: Bean factory for application context
[org.springframework.context.support.genericapplicationcont...@fbb7cb]:
org.springframework.beans.factory.support.defaultlistablebeanfact...@aeea66
07-05-2009 04:56:56 AM
org.springframework.core.io.support.PropertiesLoaderSupport loadProperties
INFO: Loading properties file from class path resource
[hibernate.properties]
07-05-2009 04:56:56 AM
org.springframework.beans.factory.support.DefaultListableBeanFactory
preInstantiateSingletons
INFO: Pre
Plugin authors and executing parallel lifecycles
With all the headaches with plugins forking a parallel lifecycle, really looking for insights on the motivation for it? Is it to maintain the integrity of the executing mojo task, that is certain pre-conditions (phase) must be met, before the actual execution. The problem I'm facing is with a multi-module project during site generation, I have a number of plugins that are forking a parallel lifecycle and it is wreaking havoc, I wish I could turn them off without hacking the plugin. Won't an option to introspect the current phase within the mojo give the plugin authors some flexibility in making the right call? Thanks, mohan kr
RE: surefire and spring - Autowiring of methods failed
You need to include the POM file, to help you out. Thanks, mohan kr -Original Message- From: Chávez, Carlos [mailto:ccha...@agssa.net] Sent: Monday, July 06, 2009 12:19 AM To: users@maven.apache.org Subject: Re: surefire and spring - Autowiring of methods failed Hi. I mean, when I ran: mvn test, it works, no one exception is throw it when i ran: mvn site, it does not work. The following exception is showed: org.apache.maven.surefire.booter.SurefireExecutionException: org.junit.runner.notification.RunNotifier.testAborted(Lorg/junit/runner/Des cription;Ljava/lang/Throwable;)V; nested exception is java.lang.NoSuchMethodError: org.junit.runner.notification.RunNotifier.testAborted(Lorg/junit/runner/Des cription;Ljava/lang/Throwable;)V java.lang.NoSuchMethodError: org.junit.runner.notification.RunNotifier.testAborted(Lorg/junit/runner/Des cription;Ljava/lang/Throwable;)V at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestM ethod(SpringJUnit4ClassRunner.java:155) at The above exception dissapear when I use the junit version 4.4. But now, I'm getting the following error messages: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ni.gob.cgr.siirci.facade.UsuarioFacadeTestCase': Injection of resource methods failed; nested exception is org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'usuarioFacade' must be of type [ni.gob.cgr.siirci.facade.UsuarioFacade], but was actually of type [$Proxy18] at org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.pos tProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:305) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .populateBean(AbstractAutowireCapableBeanFactory.java:998) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .autowireBeanProperties(AbstractAutowireCapableBeanFactory.java:329) at org.springframework.test.context.support.DependencyInjectionTestExecutionLis tener.injectDependencies(DependencyInjectionTestExecutionListener.java:110) at org.springframework.test.context.support.DependencyInjectionTestExecutionLis tener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75) at org.springframework.test.context.TestContextManager.prepareTestInstance(Test ContextManager.java:255) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(S pringJUnit4ClassRunner.java:111) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMe thod(SpringJUnit4ClassRunner.java:148) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.ja va:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44 ) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJU nit4ClassRunner.java:97) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(Ab stractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractD irectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireB ooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:100 9) Caused by: org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'usuarioFacade' must be of type [ni.gob.cgr.siirci.facade.UsuarioFacade], but was actually of type [$Proxy18] at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Abst ractBeanFactory.java:322) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra ctBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra ctBeanFactory.java:168) at org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.aut owireResource(CommonAnnotationBeanPostProcessor.java:435
RE: maven assembly plugin problem.
Did you try the outputFileNameMapping in the dependencySet descriptor for
assembly?
outputFileNameMapping${artifact.artifactId}-${artifact.baseVersion}${dashC
lassifier?}.${artifact.extension}/outputFileNameMapping
Notice the version it is ${artifact.baseVersion} and *not*
${artifact.version}
Thanks,
mohan kr
-Original Message-
From: Alexander Vaysberg [mailto:w...@vaisberg.de]
Sent: Wednesday, July 01, 2009 2:42 AM
To: Maven Users List
Subject: maven assembly plugin problem.
Hi,
I have a problem with assembly plugin. I have a standalone application
and I make for this app a jar with manifest. In manifest set I a
Main-Class and all dependencies for this app with jar plugin. That work
fine. Than, I create with assembly the zip and get the all dependencies
in lib. But I have a problem with SNAPSHOT jars. I have 5 SNAPSHOT jars.
3-Jars copy the assembly as so:- db-1.0.0-SNAPSHOT.jar, but for 2 -jars
so same as: - firm-db-data-0.0.122-20090623.122812-2.jar. That is a date
and time. For Deploying use I the Archiva.
The jar plugin write in Manifest firm-db-data-0.0.122-SNAPSHOT. But the
assembly put the dependency as firm-db-data-0.0.122-20090623.122812-2. I
need the solution for this problem.
Alexander Vaysberg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Logging Plugin Version Without Debug -X Mode
Hi, my mail client looks like messed up the formatting. Also I am assuming
that you do
have the maven-plugin-plugin configured, right?
/**
* @parameter expression=${plugin.version}
*
*/
private String pluginVersion;
Notice the quotes around the expression. I have been using this for my own
plugin and
it does work..
Thanks,
mohan kr
-Original Message-
From: Christiaan Veerman [mailto:christiaan.veerman.ma...@gmail.com]
Sent: Friday, June 26, 2009 12:36 PM
To: Maven Users List
Subject: Re: Logging Plugin Version Without Debug -X Mode
When I try:
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
The resulting string is null...
On Thu, Jun 25, 2009 at 9:04 PM, Mohan KRkmoh@gmail.com wrote:
Why don't you inject a parameter with expression ${plugin.version} in the
Mojo and
use the info level to log it? Don't know if that's what you are asking...
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
..
Thanks,
mohan kr
-Original Message-
From: Christiaan Veerman [mailto:christiaan.veerman.ma...@gmail.com]
Sent: Thursday, June 25, 2009 3:44 PM
To: users@maven.apache.org
Subject: Logging Plugin Version Without Debug -X Mode
Hello:
I am trying to find how to log the plugin version when running my plugin.
The reason I ask is that my plugin version is not explicitly set so
maven will bring down a new version with the default daily interval
(hopefully).
The question I have is how can I get the plugin version currently
running inside the mvn reaction without running in debug mode -X.
Any help is greatly appreciated.
Cheers,
Christiaan
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Logging Plugin Version Without Debug -X Mode
Why don't you inject a parameter with expression ${plugin.version} in the
Mojo and
use the info level to log it? Don't know if that's what you are asking...
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
..
Thanks,
mohan kr
-Original Message-
From: Christiaan Veerman [mailto:christiaan.veerman.ma...@gmail.com]
Sent: Thursday, June 25, 2009 3:44 PM
To: users@maven.apache.org
Subject: Logging Plugin Version Without Debug -X Mode
Hello:
I am trying to find how to log the plugin version when running my plugin.
The reason I ask is that my plugin version is not explicitly set so
maven will bring down a new version with the default daily interval
(hopefully).
The question I have is how can I get the plugin version currently
running inside the mvn reaction without running in debug mode -X.
Any help is greatly appreciated.
Cheers,
Christiaan
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Putting instrumented classes on the classpath
Maybe you can put have *two* executions of the antrun plugin? But, going to the original issue, it appears that the instrumented cobertura classes *should* be in the classpath of the maven reactor? Because I look at the source for the instrumented goal..this is what it shows // Set the instrumented classes to be the new output directory (for other plugins to pick up) project.getBuild().setOutputDirectory( instrumentedDirectory.getPath() ); System.setProperty( project.build.outputDirectory, instrumentedDirectory.getPath() ); Thanks, mohan kr -Original Message- From: lvdpal [mailto:lvd...@lunaris-informatica.nl] Sent: Wednesday, June 24, 2009 7:18 AM To: users@maven.apache.org Subject: Putting instrumented classes on the classpath Hello, I've tried to put the classes that were instrumented by Cobertura on the classpath so EasyB could find them. Just so Cobertura could see that my classes are in fact tested. I had found a solution based on the Maven Antrun plugin, but due to a bug in this plugin (which I reported in Jira: http://jira.codehaus.org/browse/MANTRUN-112 ) it isn't working. Does anybody have any other ideas on how to accomplish this? Regards, Linda -- View this message in context: http://www.nabble.com/Putting-instrumented-classes-on-the-classpath-tp241836 79p24183679.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Sharing checkstyle configuration across multiple maven projects
Just curious apart from the bug, what is the reasoning behind 'protecting' a cs configuration ? Just trying to understand the 'abuse' part. Thanks, mohan kr -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Tuesday, June 23, 2009 1:24 AM To: Maven Users List Subject: Re: Sharing checkstyle configuration across multiple maven projects It's even nicer if you need to control the access to such resource and bugs come by (http://jira.codehaus.org/browse/MCHECKSTYLE-109, http://jira.codehaus.org/browse/PLXCOMP-128) To share such common resources and configuration (checkstyle, license, ..) with other maven projects I needed a maven project with all the maven goodies, that everyone in an intranet only could use but not abuse. To get eclipse-cs to use same configuration, project is under svn and release plugin tags releases nicely, and eclipse-cs configuration is a viewvc enabled path which is long and nasty but named and eclipse-cs supports authentication for remote configuration. Regards, Stevo. 2009/6/23 Stephen Connolly stephen.alan.conno...@gmail.com it's even better if your source control is subversion fronted by apache... 2009/6/23 Mohan KR kmoh@gmail.com: I have always used the remote location for checkstyle, especially for sharing cs configuration for *disconnected* projects. And then nice thing is if using eclipse, with eclipse-cs I check in the .checkstyle and we have everything synced up nicely. Of course, you need to *host* the checkstyle file for this, apache httpd works really nice. Thanks, mohan kr -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Monday, June 22, 2009 3:13 PM To: Maven Users List Subject: Re: Sharing checkstyle configuration across multiple maven projects There was a difference between my attached example and one here http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi- module-config.html, instead of defining maven-checkstyle-plugin in build/plugins section I've defined it in build/pluginManagement/plugins section. Second mistake was that shared-resources (build-tools) inherited parent that's aggregating it causing cyclic dependency. Regards, Stevo. On Mon, Jun 22, 2009 at 5:58 PM, Todd Thiessen thies...@nortel.com wrote: What you could do is point to an actual version of your checkstyle config. ie: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId dependencies dependency groupId.../groupId artifactId.../artifactId version.../version /dependency /dependencies /plugin Instead of the using the configLocation parameter. This way any of your modules can point to the artifact without having to know its folder location. --- Todd Thiessen -Original Message- From: Stevo Slavic [mailto:ssla...@gmail.com] Sent: Monday, June 22, 2009 11:50 AM To: users@maven.apache.org Subject: Sharing checkstyle configuration across multiple maven projects Hello Maven users, I'm trying to configure a maven project to serve as parent project for multiple other maven projects. One of the things parent was supposed to do is share checkstyle configuration. To accomplish this I've tried by following example given here http://maven.apache.org/plugins/maven-checkstyle-plugin/examp les/multi-module-config.html . Attached are two project, pappa in role of a capo di tutti capi parent pom, and aproject as a simple project being pappa's child. Unfortunately, this doesn't work as expected, checkstyle configuration doesn't get found when trying to generate site for aproject. Little bit of debugging revealed that maven complains at a config location URL (see [1]). Are there any workarounds to this? I'm thinking of spring framework's pseudo URL prefix classpath:, is something like that available in maven 2? Regards, Stevo. [1] aproject's maven build output snippet [INFO] Generating Checkstyle report. [DEBUG] URLResourceLoader: Exception when looking for 'checkstyle/checks.xml' at '' java.net.MalformedURLException: no protocol: checkstyle/checks.xml at java.net.URL.init(URL.java:567) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at org.codehaus.plexus.resource.loader.URLResourceLoader.getResou rceAsInputStream(URLResourceLoader.java:45) at org.codehaus.plexus.resource.DefaultResourceManager.getResourc eAsInputStream(DefaultResourceManager.java:77) at org.codehaus.plexus.resource.DefaultResourceManager.getResourc eAsFile(DefaultResourceManager.java:117) at org.apache.maven.plugin.checkstyle.CheckstyleReport.getConfigF ile(CheckstyleReport.java:1132
RE: Sharing checkstyle configuration across multiple maven projects
I have always used the remote location for checkstyle, especially for sharing cs configuration for *disconnected* projects. And then nice thing is if using eclipse, with eclipse-cs I check in the .checkstyle and we have everything synced up nicely. Of course, you need to *host* the checkstyle file for this, apache httpd works really nice. Thanks, mohan kr -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Monday, June 22, 2009 3:13 PM To: Maven Users List Subject: Re: Sharing checkstyle configuration across multiple maven projects There was a difference between my attached example and one herehttp://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi- module-config.html, instead of defining maven-checkstyle-plugin in build/plugins section I've defined it in build/pluginManagement/plugins section. Second mistake was that shared-resources (build-tools) inherited parent that's aggregating it causing cyclic dependency. Regards, Stevo. On Mon, Jun 22, 2009 at 5:58 PM, Todd Thiessen thies...@nortel.com wrote: What you could do is point to an actual version of your checkstyle config. ie: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId dependencies dependency groupId.../groupId artifactId.../artifactId version.../version /dependency /dependencies /plugin Instead of the using the configLocation parameter. This way any of your modules can point to the artifact without having to know its folder location. --- Todd Thiessen -Original Message- From: Stevo Slavic [mailto:ssla...@gmail.com] Sent: Monday, June 22, 2009 11:50 AM To: users@maven.apache.org Subject: Sharing checkstyle configuration across multiple maven projects Hello Maven users, I'm trying to configure a maven project to serve as parent project for multiple other maven projects. One of the things parent was supposed to do is share checkstyle configuration. To accomplish this I've tried by following example given here http://maven.apache.org/plugins/maven-checkstyle-plugin/examp les/multi-module-config.html . Attached are two project, pappa in role of a capo di tutti capi parent pom, and aproject as a simple project being pappa's child. Unfortunately, this doesn't work as expected, checkstyle configuration doesn't get found when trying to generate site for aproject. Little bit of debugging revealed that maven complains at a config location URL (see [1]). Are there any workarounds to this? I'm thinking of spring framework's pseudo URL prefix classpath:, is something like that available in maven 2? Regards, Stevo. [1] aproject's maven build output snippet [INFO] Generating Checkstyle report. [DEBUG] URLResourceLoader: Exception when looking for 'checkstyle/checks.xml' at '' java.net.MalformedURLException: no protocol: checkstyle/checks.xml at java.net.URL.init(URL.java:567) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at org.codehaus.plexus.resource.loader.URLResourceLoader.getResou rceAsInputStream(URLResourceLoader.java:45) at org.codehaus.plexus.resource.DefaultResourceManager.getResourc eAsInputStream(DefaultResourceManager.java:77) at org.codehaus.plexus.resource.DefaultResourceManager.getResourc eAsFile(DefaultResourceManager.java:117) at org.apache.maven.plugin.checkstyle.CheckstyleReport.getConfigF ile(CheckstyleReport.java:1132) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeRep ort(CheckstyleReport.java:599) at org.apache.maven.reporting.AbstractMavenReport.generate(Abstra ctMavenReport.java:98) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDoc ument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render Module(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render (DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(Defau ltPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoa ls(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoa lWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoa l(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoa lAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTas kSegments(DefaultLifecycleExecutor.java:332
RE: Dependency-copy:exclude includeScope behaviour
I believe you need to have *two* executions of copy-dependencies goal with
in one case:
includeScopeprovided/includeScope
in the second case:
includeScopesystem/includeScope
Don't put the excludeScope element.
Thanks,
mohan kr
-Original Message-
From: Fiona Mahon [mailto:fma...@tssg.org]
Sent: Friday, June 19, 2009 5:23 AM
To: users@maven.apache.org
Subject: Dependency-copy:exclude includeScope behaviour
Hi,
I am using the dependency plugin for maven to copy an artifact and its
dependencies to a particular folder, that causes the generated artifact
to be automatically started in a container (an OSGi container in this
instance).
Without specifying any include/excludeScope parameters, all dependent
components for my artifact are getting copied over, including the ones I
have already packaged in with the artifact during compile (as those
dependencies are defined as 'compile').
My artifact has 2 kinds of dependencies, the ones that are resolved
during compile and added into the artifact jar, and the ones that will
be available (provided) at runtime inside the container.
What I want to be able to do is only copy the dependencies that are to
be provided in the container, to the container folder along with my
artifact, but not copy the dependencies I have already taken care of by
including them inside the artifact jar already (i.e. using compile scope).
What I tried was to exclude the compile scope dependencies and include
the provided dependencies (see below), but what actually happened when I
did this was that I get all the dependencies copied, both compile and
provided.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
phaseinstall/phase
goals
goalcopy/goal
/goals
/execution
execution
idcopy-dependencies/id
phaseinstall/phase
goals
goalcopy-dependencies/goal
/goals
configuration
excludeScopecompile/excludeScope
includeScopeprovided/includeScope
/configuration
/execution
/executions
configuration
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
stripVersiontrue/stripVersion
!-- this is where your dependent bundles will
go e.g. junit, log4j etc. --
outputDirectory${kf.pssdependencies.deploy.dir}/outputDirectory
/configuration
/plugin
I also tried to just exclude the compile scope, but this time I just get
the test dependencies copied over. I know there is some kind of
hierarchy of scopes but I haven't see anything anywhere explaining this.
I did see a post explaining how the code works:
public ScopeArtifactFilter( String scope )
{
if ( DefaultArtifact.SCOPE_COMPILE.equals( scope ) )
{ systemScope = true; providedScope = true; compileScope = true;
runtimeScope = false; testScope = false; }
else if ( DefaultArtifact.SCOPE_RUNTIME.equals( scope ) )
{ systemScope = false; providedScope = false; compileScope = true;
runtimeScope = true; testScope = false; }
else if ( DefaultArtifact.SCOPE_TEST.equals( scope ) )
{ systemScope = true; providedScope = true; compileScope = true;
runtimeScope = true; testScope = true; }
else
{ systemScope = false; providedScope = false; compileScope = false;
runtimeScope = false; testScope = false; }
}
However, what I really want is
SystemScope = true; providedScope = true; compileScope = false;
runtimeScope = false; testScope = false;
which doesn't seem to be accounted for.
Any help would be great, even a scope hierarchy.
Thanks,
Fiona.
--
Fiona Mahon
Pervasive Communication Services(PCS),
Applied Research
Telecommunications Software Systems Group (TSSG),
ArcLabs Research and Innovation Building,
Waterford Institute of Technology,
Carriganore Campus, Carriganore,
Co. Waterford, Ireland
www: www.tssg.org/people/fmahon
tel: +353 (0)51 302 928
fax: +353 (0)51 341 100
e-mail: fma...@tssg.org
Skype: fiona_mahon
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h
RE: Can I prevent maven from searching dependencies in localRepository?
Not sure I understood this correctly. It appears that you want to have a 1..n RELEASE repositories, that are access controlled. There are couple of ways you can go about it (I think): - if you use a Repository Manager like Nexus, you can get what you want, maintaining the same settings.xml - Or you can always have a settings.xml with various mirror settings. Or there are also options available in the Maven Client command to *override* the default settings.xml locations. Don't know if that is what you are looking for. Thanks, mohan kr -Original Message- From: gorgophol [mailto:benjamin.h...@inter.de] Sent: Wednesday, June 17, 2009 2:21 AM To: users@maven.apache.org Subject: Re: Can I prevent maven from searching dependencies in localRepository? Stephen Connolly-2 wrote: sounds like you are not using versions correctly. -SNAPSHOT versions are for untested local stuff. non-SNAPSHOT versions are pulled from repositories and have been tested. They are only produced from a build machine, so no developer should have a non-SNAPSHOT version unless it came from a remote repo Maybe we're not using versions and SNAPSHOTs as expected. It's not practicable in our context here. Well I'm the supervisor of the build server, where one central installation of maven runs, and designed the release process, trying to use maven. There are several company rules that have to be fulfilled. Every build of every java developer group in the company has to be done via this central installation. Builds can only be started out of scm (cvs in our case). Moving an artifact to another repository has to be done without re-building it, so its absolutly sure, that nothing has changed. So using SNAPSHOT gets very complicated, because first developers have to check in all their poms with all dependencies (which can count up to more than 100) with a SNAPSHOT version and test it. This could not be used, so they have to build it again, removing all SNAPSHOT entries in every of the poms (and the poms dependencies ...), check In again an re-build. Then have to test again, because there is no guarantee everything is the same as tested before. Deploying artifacts into a share-repository by re-building them is not allowed. So I always get into trouble with the local repository. Well I'm just trying to bring maven into this company, but I have to concern the development contexts already existing. In my oppinion maven seems to be flexible enough for that. This is really the last obstacle before my release process can get productive. But there are things that cannot be changed now, so I have to find a possibility to exclude localRepsitory from the artifact search process in maven. I'd prefer a solution maven might provide in his depth somewhere. My other option is to delete artifacts from localRepository after every build and deploy. -- View this message in context: http://www.nabble.com/Can-I-prevent-maven-from-searching-dependencies-in-loc alRepository--tp24054742p24068271.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Surefire 2.4.3 and POJC
I have gone through the ClassLoader documentation at the surefire site couple of times, but cannot understand what combination of forkMode, useSystemClassLoader and manifestJarOnly surefire plugin configuration will give me a POJC (plain old java classpath). (I understand forkMode *cannot* be none for POJC) Thanks in advance. Thanks, mohan kr
RE: Plugin / Tool for local repository
same here, interested in any updates on the plugin from the discussion below. Don't want to whip out another one if it already exists. Thanks, mohan kr -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Monday, June 15, 2009 9:32 AM To: Maven Users List Subject: Re: Plugin / Tool for local repository I saw an interested thread on mojo-dev about a local repository purge plugin. http://www.nabble.com/local-repository-purge-plugin-td16937047.html Any one know it status ? 2009/6/15 Henri Gomez henri.go...@gmail.com: Good stuff but I also needed the various versions of the project to be removed. 2009/6/15 Anders Hammar and...@hammar.net: http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-reposito ry-mojo.html /Anders On Mon, Jun 15, 2009 at 10:46, Henri Gomezhenri.go...@gmail.com wrote: Hi to all, I wonder if there is a plugin/tool available to clean a local repository ? After some time repository could became huge with many snapshots or versions (when using ranges) and the only way, for now, is just to clean up by hand. Repository managers like Nexus or Archiva does this cleanup, that's why I wonder if such service could exist in a maven plugin. Regards - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Negation of boolean property
Not sure the intent. But you can always *override* by passing in the key as
system property.
mvn -DexecuteUnitTest=true ...
Thanks,
mohan kr
-Original Message-
From: rajks [mailto:ra...@hotmail.com]
Sent: Thursday, May 21, 2009 2:06 AM
To: users@maven.apache.org
Subject: Negation of boolean property
Hi,
Is it possible to negate a boolean property value. I tried it like this
below and it did not work.
Is there a different syntax for negation ??
properties
executeUnitTestfalse/executeUnitTest
/properties
In surefire plugin
skip!${executeUnitTest}/skip
If not can this syntax be supported
Thanks
Raj
--
View this message in context:
http://www.nabble.com/Negation-of-boolean-property-tp23648816p23648816.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-dependency-plugin odd behaviour
Yup..seen that..be careful switching between CLI and m2eclipse..turn of
Build Automatically when running CLI..
Thanks,
mohan kr
-Original Message-
From: Adam Purkiss [mailto:ajpurk...@hotmail.com]
Sent: Thursday, May 21, 2009 2:18 PM
To: users@maven.apache.org
Subject: maven-dependency-plugin odd behaviour
I have the following setup in a POM file during a transition phase between a
massive ANT based project and trying to mavenise it. When run using the
install target from the command line with maven 2.1 I get the expected
behaviour:
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: com.intellimec.drive-sync:drive-sync-ias-common:
3.3.0-SNAPSHOT:jar
[INFO] Copying drive-sync-ias-common-3.3.0-SNAPSHOT.jar to C:\iPaid\iPaid
Application Server\lib\drive-sync-ias-common-3.3.0-SNAPSHOT.jar
When I use the Eclipse Maven plugin however setup to use 2.1 I get:
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: com.intellimec.drive-sync:drive-sync-ias-common:
3.3.0-SNAPSHOT:jar
[INFO] Copying classes to C:\iPaid\iPaid Application Server\lib\classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error copying artifact from C:\iPaid\iPaid Application
Server\maven\modules\drive-sync-ias-common\target\classes to C:\iPaid\iPaid
Application Server\lib\classes
Embedded error: C:\iPaid\iPaid Application
Server\maven\modules\drive-sync-ias-common\target\classes (Access is denied)
Any idea what is going on? I must be missing something obvious. I just dont
get why one way works and the other fails. I am running Maven 2.1 on a
Windows XP box
POM excert:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
executions
execution
idcopy/id
phaseinstall/phase
goals
goalcopy/goal
/goals
configuration
artifactItems
artifactItem
groupIdcom.intellimec.drive-sync/groupId
artifactIddrive-sync-ias-common/artifactId
version${project.version}/version
typejar/type
overWritetrue/overWrite
/artifactItem
/artifactItems
outputDirectory../../../lib/outputDirectory
/configuration
/execution
/executions
/plugin
Debug output
[DEBUG] The following artifacts were filtered out for plugin:
org.apache.maven.plugins:maven-dependency-plugin:2.1 because they're already
in the core of Maven:
org.apache.maven:maven-artifact:jar:2.0.9:runtime
org.apache.maven:maven-plugin-api:jar:2.0.9:runtime
org.apache.maven:maven-project:jar:2.0.9:runtime
org.apache.maven:maven-model:jar:2.0.9:runtime
org.apache.maven:maven-core:jar:2.0.9:runtime
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:runtim
e
org.apache.maven.reporting:maven-reporting-api:jar:2.0.6:runtime
These will use the artifact files already in the core ClassRealm instead, to
allow them to be included in PluginDescriptor.getArtifacts().
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-dependency-plugin:2.1:copy' --
[DEBUG] (s) groupId = com.intellimec.drive-sync
[DEBUG] (s) artifactId = drive-sync-ias-common
[DEBUG] (s) version = 3.3.0-SNAPSHOT
[DEBUG] (s) type = jar
[DEBUG] (s) overWrite = true
[DEBUG] (s) artifactItems =
[com.intellimec.drive-sync:drive-sync-ias-common:3.3.0-SNAPSHOT:jar]
[DEBUG] (s) local = Repository[local|file://C:\Documents and
Settings\apurkiss\.m2\repository]
[DEBUG] (f) outputAbsoluteArtifactFilename = false
[DEBUG] (s) outputDirectory = C:\iPaid\iPaid Application Server\lib
[DEBUG] (s) overWriteIfNewer = true
[DEBUG] (s) overWriteReleases = false
[DEBUG] (s) overWriteSnapshots = false
[DEBUG] (f) project = MavenProject:
com.intellimec.drive-sync:drive-sync-ias-common:3.3.0-SNAPSHOT @
C:\iPaid\iPaid Application
Server\maven\modules\drive-sync-ias-common\pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
com.intellimec.drive-sync:drive-sync-ias-common:3.3.0-SNAPSHOT @
C:\iPaid\iPaid Application
Server\maven\modules\drive-sync-ias-common\pom.xml]
[DEBUG] (s) remoteRepos =
[Repository[internal|http://coffey.imscorp.intellimec.com:8180/archiva/repos
itory/internal],
Repository[snapshots|http://coffey.imscorp.intellimec.com:8180/archiva/repos
itory/snapshots], Repository[central|http://repo1.maven.org/maven2]]
[DEBUG] (f) silent = false
[DEBUG] (s) stripVersion = false
[DEBUG] -- end configuration --
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: com.intellimec.drive-sync:drive-sync-ias-common:
3.3.0-SNAPSHOT:jar
[INFO] Copying classes to C:\iPaid\iPaid Application Server\lib\classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error copying artifact from C:\iPaid\iPaid Application
Server\maven\modules\drive-sync-ias-common\target\classes to C:\iPaid\iPaid
Application Server\lib\classes
Embedded
RE: [ANN] Maven Doxia and Doxia Sitetools 1.0 Released
So will the site plugin automatically pick this up? Thanks, mohan kr -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Sunday, March 01, 2009 6:43 AM To: annou...@maven.apache.org; Maven Users List Cc: Maven Developers List Subject: [ANN] Maven Doxia and Doxia Sitetools 1.0 Released The Maven team is pleased to announce the release of Maven Doxia and Doxia Sitetools, version 1.0. http://maven.apache.org/doxia/ Release Notes - Maven Doxia - Version 1.0 ** Task * [DOXIA-254] - Using the last version of modello-maven-plugin Release Notes - Maven Doxia Sitetools - Version 1.0 ** Bug * [DOXIASITETOOLS-13] - NPE when generating Maven site * [DOXIASITETOOLS-16] - NullPointerException * [DOXIASITETOOLS-17] - generated site.css is 0 bytes ** Improvement * [DOXIASITETOOLS-1] - Provide a schema for site.xml ** Wish * [DOXIASITETOOLS-8] - The order of title tag and meta tag Enjoy! - The Maven Team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
