Re: Duplicate name in parent and current
only because the group ids are the same 2009/3/25 Paul Gier pg...@redhat.com I think it's the duplicated artifactId's that is causing the problem. Maybe the artifactId of the pom in the subdirectory modA/modA should be set to modA-modA or something like that. huser wrote: Hi, I have a situation in which the dir names are same. Example: /base /base/modA /base/modA/modA I get the following error while trying to run mvn compile. The code for 2 POM's is below. What should I change in the parent to make this work ? Thanks, Reason: Parent element is a duplicate of the current project for project com.co.t3:modA [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parent element is a duplicate of the current project for project com.co.t3:modA at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) /base/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdt3/artifactId version1.0-SNAPSHOT/version relativePath../base/pom.xml/relativePath /parent name modA /name groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingpom/packaging version1.0-SNAPSHOT/version /base/modA/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingjar/packaging version1.0-SNAPSHOT/version - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: hibernate byte code instrumentation
attach the execution to the process-classes phase 2009/3/26 fachhoch fachh...@gmail.com I am using maven-ant-run plugin to call hibernate byte code insturmentation , i also have maven jetty plugin , every time i run jetty plugin first all modified java files gets complied and then test cases and finally deployed , but this ant-run plugin for hibernate byte code instrumentation does not get called , please tell me how to call hibernate byte code automatically ? -- View this message in context: http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22714675.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
Re: How to perform a deploy only
Well you could stage them yourself You need a staging repository... I see no reason why this cannot be file based You then need to do some scripting and use the maven-stage-plugin ( http://maven.apache.org/plugins/maven-stage-plugin/index.html) to copy the contents of the staging repository to the real repository. I normally have the distribution repository defined by a property in settings.xml... so that you can just run mvn deploy -Ddistribution.url=file:///staging-repo and then run an ant script that does the mvn stage:copy for you -Stephen 2009/3/26 Jim McCaskey jim.mccas...@pervasive.com Thanks for the suggestion. I have been trying to avoid using repository managers for a number of reasons that are beyond the scope of this thread. I may have to break down eventually... I'm surprised no one has needed this sort of feature, or maybe they have and that's why Nexus has the features that it does. I was hoping to find a Maven native (whatever native means in a highly pluggable architecture) way to do this that would not take much additional work. mvn -DdoNothingButDeploy=true deploy That would be about perfect. :) Would this even be consider for an enhancement request if I opened it? Perhaps I am the only one interested in such a thing. Thanks! -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:55 PM To: Maven Users List Subject: RE: How to perform a deploy only Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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: Possible problem when multiple developers depend on SNAPSHOT versions
Hello Trevor, contrary to some responses here I don't think your issues is SCM/Version Control issue. This is not your fault. Your issue is missing soft or dynamic version support in maven. Actually the responses propose some workarounds: 1.Manual: An easy solution is: When Alice prepares the release, she says Hey Bob, I'm doing a release of Foo. This is obviously not a solution if ther is not just foo but foo1, foo2 to fo10 and AppA to AppZ. 2. Custom scripts We use a little script that invokes the version plugin and checks in the pom.xml if versions were updated. Hudson runs the update script nightly. This looks like a working solution. However a native Maven Solution would be better. 3. innhouse parent pom workaround Use an inhouse global POM that is used as parent everywhere and define the versions used there in a depMgmt section. How can you make sure you always use the latest version of the parent POM? This changes the problem from updating the reference to foo into updating the reference to the parent. I'm new to maven and have used ant ivy before. With ivy you're able to design AppA an AppB so they will always pick up the latest version of foo. However a released artifact can still contain information about the exact version used to build the artifact. I'm really missing this feature in maven. An if I look at your post and the proposed workarounds I think others are missing it a well, maybe they just don't know... I've already posted about this isse before, but there has not been any response yet: http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html Best regards, Martin 2009/3/26 Martin Gainty mgai...@hotmail.com The only way to accomplish this is called version control but since you do not want to use version control .. how do you achieve intelligent merging *on the same component codebase* without version control ? Martin __ Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Subject: RE: Possible problem when multiple developers depend on SNAPSHOT versions Date: Wed, 25 Mar 2009 22:18:53 -0400 From: justin.edel...@mtvstaff.com To: users@maven.apache.org +10 From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com] Sent: Wed 3/25/2009 5:49 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way around this. // ben On Wed, Mar 25, 2009 at 20:10, Trevor Harmon tre...@vocaro.com wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to
Re: Possible problem when multiple developers depend on SNAPSHOT versions
2009/3/26 Martin Eigenbrodt martineigenbr...@googlemail.com Hello Trevor, contrary to some responses here I don't think your issues is SCM/Version Control issue. This is not your fault. Your issue is missing soft or dynamic version support in maven. Actually the responses propose some workarounds: 1.Manual: An easy solution is: When Alice prepares the release, she says Hey Bob, I'm doing a release of Foo. This is obviously not a solution if ther is not just foo but foo1, foo2 to fo10 and AppA to AppZ. 2. Custom scripts We use a little script that invokes the version plugin and checks in the pom.xml if versions were updated. Hudson runs the update script nightly. This looks like a working solution. However a native Maven Solution would be better. eh... how is invoking a maven plugin not a native maven solution 3. innhouse parent pom workaround Use an inhouse global POM that is used as parent everywhere and define the versions used there in a depMgmt section. How can you make sure you always use the latest version of the parent POM? This changes the problem from updating the reference to foo into updating the reference to the parent. mvn versions:update-parent presto-chango you now have the latest deployed parent I'm new to maven and have used ant ivy before. With ivy you're able to design AppA an AppB so they will always pick up the latest version of foo. However a released artifact can still contain information about the exact version used to build the artifact. I'm really missing this feature in maven. An if I look at your post and the proposed workarounds I think others are missing it a well, maybe they just don't know... I've already posted about this isse before, but there has not been any response yet: http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html Best regards, Martin 2009/3/26 Martin Gainty mgai...@hotmail.com The only way to accomplish this is called version control but since you do not want to use version control .. how do you achieve intelligent merging *on the same component codebase* without version control ? Martin __ Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Subject: RE: Possible problem when multiple developers depend on SNAPSHOT versions Date: Wed, 25 Mar 2009 22:18:53 -0400 From: justin.edel...@mtvstaff.com To: users@maven.apache.org +10 From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com] Sent: Wed 3/25/2009 5:49 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way around this. // ben On Wed, Mar 25, 2009 at 20:10, Trevor Harmon tre...@vocaro.com wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for
Re: Test built jar
ping ^^ andy petrella a écrit : Hi All, I trying to have some IT tests (or look-like) on my jar file only. I was thinking that the phase verify will give me that chance but not. Here is my problem. I have a jar where some directory has to be parsed on a file pattern = I use the JarFile class, then parse it to retrieve what I need (some XML files). This code must be tested (a lot !) but I can figure out how to have my tests' classpath running on the generated test and not on target/classses. (a maven -X shows me that target/classes are used while my It test are executed using the surfire conf in the verify phase) Ideas someone ? Thanks a lot. ap - 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: Possible problem when multiple developers depend on SNAPSHOT versions
SNIP 2. Custom scripts We use a little script that invokes the version plugin and checks in the pom.xml if versions were updated. Hudson runs the update script nightly. This looks like a working solution. However a native Maven Solution would be better. eh... how is invoking a maven plugin not a native maven solution The Plugin is native. A little script invoking the version plugin is not native since you need that script and make sure it is invoked before every build. (Or at least nightly ..) //Martin Eigenbrodt 3. innhouse parent pom workaround Use an inhouse global POM that is used as parent everywhere and define the versions used there in a depMgmt section. How can you make sure you always use the latest version of the parent POM? This changes the problem from updating the reference to foo into updating the reference to the parent. mvn versions:update-parent presto-chango you now have the latest deployed parent I know this, but again it is a manual solution. If you want AppB (I'm using the originall posters example) to stay up to date you have to make sure versions:update-parent is called before every build and you have your pom changed each time and so need a scm checkin. This is a complicated workaround for the missing feature: parent artifactIdfoo/artifactId versionLATEST/version /parent I'm new to maven and have used ant ivy before. With ivy you're able to design AppA an AppB so they will always pick up the latest version of foo. However a released artifact can still contain information about the exact version used to build the artifact. I'm really missing this feature in maven. An if I look at your post and the proposed workarounds I think others are missing it a well, maybe they just don't know... I've already posted about this isse before, but there has not been any response yet: http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html Best regards, Martin 2009/3/26 Martin Gainty mgai...@hotmail.com The only way to accomplish this is called version control but since you do not want to use version control .. how do you achieve intelligent merging *on the same component codebase* without version control ? Martin __ Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Subject: RE: Possible problem when multiple developers depend on SNAPSHOT versions Date: Wed, 25 Mar 2009 22:18:53 -0400 From: justin.edel...@mtvstaff.com To: users@maven.apache.org +10 From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com] Sent: Wed 3/25/2009 5:49 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way around this. // ben On Wed, Mar 25, 2009 at 20:10, Trevor Harmon tre...@vocaro.com wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing
Re: How to integrate xhtml files into a maven generated site?
Hi Lukas Theussl wrote: This doesn't work with doxia-1.0, it's fixed in doxia-1.1 which is not used yet by the site plugin. There is a snapshot of the site plugin (version 2.1-SNAPSHOT) that uses doxia 1.1 but it requires maven 2.1 I tried maven 2.1 and doxia 1.1 and get this exception: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site': Unable to load the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class is missing: org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext Did I miss something regards Pascal -- View this message in context: http://www.nabble.com/How-to-integrate-xhtml-files-into-a-maven-generated-site--tp22601841p22717300.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
Re: How to perform a deploy only
On Thu, Mar 26, 2009 at 03:17, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. My Guess: It sounds like you're describing a multi-module build where the top-level pom naming the modules to be built is also parent to the sub-modules. You want to deploy just the top-level pom, so others can build against it. Correct? You don't want to deploy all the sub-modules each time you do this because they may not be in a stable state. (1) Have you considered mvn --non-recursive deploy? (2) You do realize that the pom that defines the modules does not have to be the same as the common parent pom, yes? http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-multi-vs-inherit.html#fig-maven-book // ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to integrate xhtml files into a maven generated site?
As I said, you can't use site-plugin-2.0-beta-7 (btw latest version is 2.0) with doxia 1.1. Try version 2.1-SNAPSHOT. HTH, -Lukas feensturm wrote: Hi Lukas Theussl wrote: This doesn't work with doxia-1.0, it's fixed in doxia-1.1 which is not used yet by the site plugin. There is a snapshot of the site plugin (version 2.1-SNAPSHOT) that uses doxia 1.1 but it requires maven 2.1 I tried maven 2.1 and doxia 1.1 and get this exception: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site': Unable to load the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class is missing: org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext Did I miss something regards Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Test built jar
ping ^^ I think no one replied because your message does not make any sense (to me at least). Can you try re-writing the email and focus on what you have, what you need, and how you think Maven can help get you from A to B? Also mention what you've tried and why that didn't work or was insufficient. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Exclude resources during jar generation
When I generate jar from A project, I would like to exclude these resources (containing in src/main/resources) from my jar. For the moment, I haven't found a solution. Make project D which is just the assembly, and don't put any files in D/src/main/resources, just let D be your assembly project. (This assumes I understood your email, which may not be a correct assumption.) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-release-plugin: branch goal does not take same properties as prepare goal
Hello, I am trying to automate the branching for a few hundred Maven projects. The automation of creating a release works great using the -DreleaseVersion and -DdevelopmentVersion properties using the prepare goal. The documentation of the branch goals states this: The branch goal can use the same properties used by the prepare goal for specifying the versions to be used. It seems that I can't use the version properties from the release goal, but that I should specify these: project.[rel|dev].org.myCompany:projectA However, these properties contain project specific information, which means that I can't use the multi-module approach to automate the branching for all my projects at once. Our versioning strategy always takes the same major/minor number and branch name for modules going together in a release. Am I missing something? Any hints on how to get around this? Ringo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-release-plugin, svn 1.5 issue and dependencies
Hi, The vote (maven-scm and maven-release-plugin) has started 2 days ago. (vote thread : [1]) I'm currently waiting the end of the release process to push artifacts on the central repo (the end for me is today 11H55 PM Paris Time ) BTW you can try with the staged artifacts. HTH, -- Olivier [1] http://www.nabble.com/-VOTE--Release-Maven-Scm-1.2-and-maven-release-plugin-2.0-beta-9-tt22671100.html 2009/3/26 Stevo Slavić ssla...@gmail.com: Hello maven users, In maven-release-plugin recently an important issue ( http://jira.codehaus.org/browse/MRELEASE-375 ) has been resolved. Without this fix, release plug-in can not be used on a multi-module project (with svn 1.5.0+ client) - dunno about others, but I rarely work on a single module project, and even more rarely use release plugin on a single module project. Eager to test the fix, I tried to use 2.0-beta-9-SNAPSHOT version of the plugin. Just as note to other, for it to be used, I had to add http://repository.apache.org/snapshots as both dependency repository (because release plugin depends on maven-release-manager:2.0-beta-9-SNAPSHOT) and as plugin repository. Because of fix importance, are there any plans to release 2.0-beta-9 any time soon? Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-release-plugin, svn 1.5 issue and dependencies
Hello maven users, In maven-release-plugin recently an important issue ( http://jira.codehaus.org/browse/MRELEASE-375 ) has been resolved. Without this fix, release plug-in can not be used on a multi-module project (with svn 1.5.0+ client) - dunno about others, but I rarely work on a single module project, and even more rarely use release plugin on a single module project. Eager to test the fix, I tried to use 2.0-beta-9-SNAPSHOT version of the plugin. Just as note to other, for it to be used, I had to add http://repository.apache.org/snapshots as both dependency repository (because release plugin depends on maven-release-manager:2.0-beta-9-SNAPSHOT) and as plugin repository. Because of fix importance, are there any plans to release 2.0-beta-9 any time soon? Regards, Stevo.
Re: maven-release-plugin, svn 1.5 issue and dependencies
Great! Thanks for quick reply! 2009/3/26 Olivier Lamy ol...@apache.org Hi, The vote (maven-scm and maven-release-plugin) has started 2 days ago. (vote thread : [1]) I'm currently waiting the end of the release process to push artifacts on the central repo (the end for me is today 11H55 PM Paris Time ) BTW you can try with the staged artifacts. HTH, -- Olivier [1] http://www.nabble.com/-VOTE--Release-Maven-Scm-1.2-and-maven-release-plugin-2.0-beta-9-tt22671100.html 2009/3/26 Stevo Slavić ssla...@gmail.com: Hello maven users, In maven-release-plugin recently an important issue ( http://jira.codehaus.org/browse/MRELEASE-375 ) has been resolved. Without this fix, release plug-in can not be used on a multi-module project (with svn 1.5.0+ client) - dunno about others, but I rarely work on a single module project, and even more rarely use release plugin on a single module project. Eager to test the fix, I tried to use 2.0-beta-9-SNAPSHOT version of the plugin. Just as note to other, for it to be used, I had to add http://repository.apache.org/snapshots as both dependency repository (because release plugin depends on maven-release-manager:2.0-beta-9-SNAPSHOT) and as plugin repository. Because of fix importance, are there any plans to release 2.0-beta-9 any time soon? Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Test built jar
ok :) What I need is to be able to test the behavior of my code when the jar is attached to the classpath instead of the classes folder. Because, I have a code that parse the content of the jar where it stands to find xml files or use getResourceAsStream to get the folder. So the code checks if the context is jar or not, then execute the corresponding code. The code using getResourceAsStream is well tested but the other cannot because surefire adds the folder target/classes to the classpath rather than (in my case) the built jar. Sorry if it wasn't clear, or still not clear. If it doesn't make sense, what can I do (other than : created a project having a dependency on the to-be-tested project...) Thanks ap Wayne Fay a écrit : ping ^^ I think no one replied because your message does not make any sense (to me at least). Can you try re-writing the email and focus on what you have, what you need, and how you think Maven can help get you from A to B? Also mention what you've tried and why that didn't work or was insufficient. Wayne - 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
Code coverage reports Activating profile if (site) plug-in is run
Hello maven users, Is there a way to activate a profile based on plug-in being run? I'm trying to find a workaround for issue present in both free open source code coverage maven report options, cobertura and emma (if there are more, please let me know). AFAIK, both, to produce report, run code instrumentalization, execute test phase in lifecycle separate from default, and then generate output. Problem is that test phase is so to speak hardcoded, so surefire execution configured to run in integration-test phase doesn't get run and coverage data will apear to be lower than what they actually are. Typicaly I use TestNG for tests, and it's test groups feature, separating tests in at least unit, and integration and/or functional test groups. Then I configure surefire to run unit tests in test phase, and all the others in integration-test phase. If profile could be activated based on plug-in being run, workaround would be to create a profile, activeted on e.g. site plug-in being run, and in that profile surefire could be configured to contain only one default execution on test phase but would include all the tests. IMO, best solution would be to have following (in cobertura case, longstanding) issues fixed ( http://jira.codehaus.org/browse/MCOBERTURA-86 , http://jira.codehaus.org/browse/MOJO-1299 ) Regards, Stevo.
Re: XHTML to PDF with doxia-maven-plugin, ignore some tags
I can't remove the anchor because my xhtml is generated from an existing html (used by others applications, so i can't modify it). Thanks for your response, i'll developped my own tool to remove specifics xhtml tags. Lukas Theussl-3 wrote: Not sure I understand but if you don't want an anchor, why not just remove it? Anyway, you can't tell a parser to ignore one tag and not the other. HTH, -Lukas niamande wrote: I've got a xhtml with an anchor before a section : ..l txt1 div class=section.. /div How indicate to doxia plugin to ignore this anchor ? I don't want that it appears in the generated pdf. Thanks ! -- View this message in context: http://www.nabble.com/XHTML-to-PDF-with-doxia-maven-plugin%2C-ignore-some-tags-tp22702451p22718534.html Sent from the Doxia - Users mailing list archive at Nabble.com.
Maven extra sources and eclipse
Hi all We have a projet ( http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml ) using a parser generator , for which we have extra Java sources, not for building with the application. We generate the eclipse configuration with Maven, but I found no way to specify these extra Java sources so that they appear in the eclipse configuration. Thanks for any hint -- Jean-Marc Vanel Consulting, services, training, Rule-based programming, Semantic Web http://jmvanel.free.fr/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven dependency for JAI?
Hi, is there a maven dependency for Java Advanced Imaging projects? thanks. -- View this message in context: http://www.nabble.com/Maven-dependency-for-JAI--tp22719872p22719872.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
Re: setting surefire reports directory
Hi, thank you for your answers. Reinhards infos solve exactly my problem. Of course I knew the luntbuild-property artifactsDir. But I missed the solution from Reinhard how I simply integrate this property in the pom.xml without forcing the user to set the artifactsDir at every call or integrate a default-artifactsDir in every profile! Norbert -- View this message in context: http://www.nabble.com/setting-surefire-reports-directory-tp22702724p22720009.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
Re: [Vote] findbugs-maven-plugin v 2.0 release
+1 2009/3/26 Garvin LeClaire garvin.lecla...@gmail.com The Maven Findbugs team would like to release Maven Findbugs Plugin version 2.0 This plugin allows the developer to run Findbugs analysis against a Maven project and produce site output in HTML to match other site reports. There are option to produce other XML outputs which are used by other plugins. Issues fixed in this release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=14335pid=11701status=6sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC More information can be found at the plugin site: http://mojo.codehaus.org/findbugs-maven-plugin/ Issues Can be registered in JIRA at: http://jira.codehaus.org/browse/MFINDBUGS More information on FindBugs http://findbugs.sourceforge.net/index.html You can test the Maven Findbugs Plugin in your own project by adding the following dependency: dependency groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.0-SNAPSHOT/version /dependency *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will require Maven to be run with a minimum of Java 5. This is consistent with Findbugs requirement for their versions of 1.3.X and greater. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Regards, Garvin LeClaire garvin.lecla...@gmail.com
Apache maven snapshots repository root links are invalid
Hello maven users, Links on http://repository.apache.org/snapshots are invalid, they are missing snapshots part. This is error only in the root of the repository, once in some directory e.g. http://repository.apache.org/snapshots/org;, links work well. It seems to be some sort of (nexus) configuration issue. Regards, Stevo.
Re: Possible problem when multiple developers depend on SNAPSHOT versions
2009/3/26 Martin Eigenbrodt martineigenbr...@googlemail.com SNIP 2. Custom scripts We use a little script that invokes the version plugin and checks in the pom.xml if versions were updated. Hudson runs the update script nightly. This looks like a working solution. However a native Maven Solution would be better. eh... how is invoking a maven plugin not a native maven solution The Plugin is native. A little script invoking the version plugin is not native since you need that script and make sure it is invoked before every build. (Or at least nightly ..) //Martin Eigenbrodt 3. innhouse parent pom workaround Use an inhouse global POM that is used as parent everywhere and define the versions used there in a depMgmt section. How can you make sure you always use the latest version of the parent POM? This changes the problem from updating the reference to foo into updating the reference to the parent. mvn versions:update-parent presto-chango you now have the latest deployed parent I know this, but again it is a manual solution. If you want AppB (I'm using the originall posters example) to stay up to date you have to make sure versions:update-parent is called before every build and you have your pom changed each time and so need a scm checkin. This is a complicated workaround for the missing feature: parent artifactIdfoo/artifactId versionLATEST/version /parent And that prevents your build from being reproducible... note that AFAIK is nothing stopping you from using a range parent version[1.0,2.0-!)/version /parent (Of course you'd face the same issues as LATEST) I'm new to maven and have used ant ivy before. With ivy you're able to design AppA an AppB so they will always pick up the latest version of foo. However a released artifact can still contain information about the exact version used to build the artifact. I'm really missing this feature in maven. An if I look at your post and the proposed workarounds I think others are missing it a well, maybe they just don't know... I've already posted about this isse before, but there has not been any response yet: http://www.nabble.com/Soft-dependency-versions-combined-with-repeatable-builds-td22697640.html Best regards, Martin 2009/3/26 Martin Gainty mgai...@hotmail.com The only way to accomplish this is called version control but since you do not want to use version control .. how do you achieve intelligent merging *on the same component codebase* without version control ? Martin __ Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Subject: RE: Possible problem when multiple developers depend on SNAPSHOT versions Date: Wed, 25 Mar 2009 22:18:53 -0400 From: justin.edel...@mtvstaff.com To: users@maven.apache.org +10 From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com] Sent: Wed 3/25/2009 5:49 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way
Re: How to integrate xhtml files into a maven generated site?
Ok, I mixed up with the answer from Marco Huber Marco Huber wrote: So I wait for maven 2.1 until I can add my documentation to the project :-( But with the Snapshot I get the same exception: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site': Unable to load the mojo 'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class is missing: org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext regards Pascal -- View this message in context: http://www.nabble.com/How-to-integrate-xhtml-files-into-a-maven-generated-site--tp22601841p22721345.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
Re: Maven extra sources and eclipse
Hi, You can use build-helper plugin and its goal add-source. http://mojo.codehaus.org/build-helper-maven-plugin/ rgds, Markku Jean-Marc Vanel wrote: Hi all We have a projet ( http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml ) using a parser generator , for which we have extra Java sources, not for building with the application. We generate the eclipse configuration with Maven, but I found no way to specify these extra Java sources so that they appear in the eclipse configuration. Thanks for any hint - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
snip parent artifactIdfoo/artifactId versionLATEST/version /parent And that prevents your build from being reproducible... Not If you combine dynamic version ranges with replacement during deploy and release the builds remain reproducable. They are in fact even more reproducable than now. Example: You trunk would contain: parent versionlatestversion /parent a tag in svn or a resolved pom within a jar/war/ whatever should automatically have the used version written in: parent version1.2.3/version /parent If you then stop using SNAPSHOT versions an have your CI Server produces a new version for every Build each single build becomes reproducable which is even more than you have now. In my opinion that is what on should aim for. The only difference between a CI build and a release is that a release has been tested and marked as good. So each CI build is a potential release and as such should be reproducable. parent version[1.0,2.0-!)/version /parent I've tried that and it doesn't work. Theres even an ticket for that one: http://jira.codehaus.org/browse/MNG-2199 There are in fact more tickets about using latest version and dynamic version replacement (or replacing properties)
Re: How to perform a deploy only
I don't really see the problem here. mvn clean install mvn deploy:deploy I'm sure there is an equivalent if you're building under Windows. Stefan On Wed, 25 Mar 2009 21:37:29 -0500 Jim McCaskey jim.mccas...@pervasive.com wrote: I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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 -- Mit freundlichen Grüßen, Stefan Seidel Software-Entwickler VUB Printmedia GmbH Chopinstraße 4, 04103 Leipzig tel.+49 (341) 9 60 50 93 fax.+49 (341) 9 60 50 92 mail. ssei...@vub.de web.www.vub.de VUB Printmedia GmbH HRB Köln 24015 GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Continuum 1.3.2 (Beta) Released
The Apache Continuum team is pleased to announce the release of Apache Continuum 1.3.2 (Beta). Apache Continuum is an enterprise-ready continuous integration server with features such as automated builds, release management, role-based security, and integration with popular build tools and source control management systems. The latest release can be downloaded from: http://continuum.apache.org/download.html ~ The Apache Continuum Team
Re: How to integrate xhtml files into a maven generated site?
Where did you get the snapshot from? Are you using the new snapshot repo http://repository.apache.org/snapshots ? (not the old one at people.apache.org). If that's not it please attach the full stack trace. cheers, -Lukas feensturm wrote: Ok, I mixed up with the answer from Marco Huber Marco Huber wrote: So I wait for maven 2.1 until I can add my documentation to the project :-( But with the Snapshot I get the same exception: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site': Unable to load the mojo 'org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin'. A required class is missing: org/apache/maven/doxia/module/xhtml/decoration/render/RenderingContext org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext regards Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to perform a deploy only
Brian. I think what Jim is asking for is very reasonable. You just did a full install of your multi-module project to ensure they all pass and work as you expect to avoid encoutering those errors when doing a deploy and only having 1/2 your projects up on your nexus repo. This isn't as important for cutting new releases, since there is the release plugin, but for deploying snapshots it would be nice to ensure all projects pass all tests before deploying any of them. So running a mvn install, then a mvn deployOnly work flow I think is very reasonable. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 10:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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: How to integrate xhtml files into a maven generated site?
Sorry if this is out of context, haven't followed the thread. For now the best way AFAIK is to just add (X)HTML files in src/site/resources and link as appropriate. hth, Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
ejb manifest -- strip version numbers of dependencies
Hello,
I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
configuration
ejbVersion2.1/ejbVersion
generateClientfalse/generateClient
archive
manifest
addClasspathtrue/addClasspath
classpathLayoutTypecustom/classpathLayoutType
customClasspathLayout${artifact.artifactId}/customClasspathLayout
/manifest
/archive
/configuration
/plugin
Michael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: How to perform a deploy only
Stephen, Ah, this sounds like a very promising work around. I was unaware of the maven-stage-plugin. Short of a method to do it with deploy directly this may work. Thanks for the suggestion! -Jim -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, March 26, 2009 1:13 AM To: Maven Users List Subject: Re: How to perform a deploy only Well you could stage them yourself You need a staging repository... I see no reason why this cannot be file based You then need to do some scripting and use the maven-stage-plugin ( http://maven.apache.org/plugins/maven-stage-plugin/index.html) to copy the contents of the staging repository to the real repository. I normally have the distribution repository defined by a property in settings.xml... so that you can just run mvn deploy -Ddistribution.url=file:///staging-repo and then run an ant script that does the mvn stage:copy for you -Stephen 2009/3/26 Jim McCaskey jim.mccas...@pervasive.com Thanks for the suggestion. I have been trying to avoid using repository managers for a number of reasons that are beyond the scope of this thread. I may have to break down eventually... I'm surprised no one has needed this sort of feature, or maybe they have and that's why Nexus has the features that it does. I was hoping to find a Maven native (whatever native means in a highly pluggable architecture) way to do this that would not take much additional work. mvn -DdoNothingButDeploy=true deploy That would be about perfect. :) Would this even be consider for an enhancement request if I opened it? Perhaps I am the only one interested in such a thing. Thanks! -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:55 PM To: Maven Users List Subject: RE: How to perform a deploy only Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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: hibernate byte code instrumentation
I did not understand this, please explain what should I change in pom to do
this ?
here is my jetty maven plugin
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version6.1.12.rc4/version
configuration
dependencies
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
version1.0.4/version
typejar/type
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.14/version
typejar/type
/dependency
/dependencies
/configuration
/plugin
here is my maven ant run plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
configuration
tasks
taskdef name=instrument
classname=org.hibernate.tool.instrument.javassist.InstrumentTask
classpath
path refid=maven.runtime.classpath /
path refid=maven.plugin.classpath /
/classpath
/taskdef
instrument verbose=true
fileset dir=${project.build.outputDirectory}
include name=**/model/**/*.class /
/fileset
/instrument
/tasks
/configuration
/plugin
please tell me what should I do to my pom to acheieve what you said .
Stephen Connolly-2 wrote:
attach the execution to the process-classes phase
2009/3/26 fachhoch fachh...@gmail.com
I am using maven-ant-run plugin to call hibernate byte code
insturmentation
, i also have maven jetty plugin , every time i run jetty plugin first
all modified java files gets complied and then test cases and finally
deployed , but this ant-run plugin for hibernate byte code
instrumentation
does not get called , please tell me how to call hibernate byte code
automatically ?
--
View this message in context:
http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22714675.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
--
View this message in context:
http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22722678.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
multi-module pom: do something after build?
Folks; maybe a strange question: At the moment I am dealing with a project containing several module/module's to be built, including a couple of .jar and a couple of .war artifacts. In order to have the .war artifacts (finalName.war) deployable to an application server, I want to configure my project to, after everything has been built, have all these .war files ($project/target/finalName.war) copied to an arbitrary folder somewhere in my file system (say, an autodeploy one). Is there a straightforward way getting this done? TIA and all the best, Kristian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Vote] findbugs-maven-plugin v 2.0 release
-1 Background: According to http://jira.codehaus.org/browse/MFINDBUGS-66, the plugin integrates Findbugs version 1.3.6. Meanwhile, version 1.3.8 was released. I suggest to catch up with that release before releasing the plugin. -- Thorsten Garvin LeClaire-2 wrote: The Maven Findbugs team would like to release Maven Findbugs Plugin version 2.0 This plugin allows the developer to run Findbugs analysis against a Maven project and produce site output in HTML to match other site reports. There are option to produce other XML outputs which are used by other plugins. Issues fixed in this release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=14335pid=11701status=6sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC More information can be found at the plugin site: http://mojo.codehaus.org/findbugs-maven-plugin/ Issues Can be registered in JIRA at: http://jira.codehaus.org/browse/MFINDBUGS More information on FindBugs http://findbugs.sourceforge.net/index.html You can test the Maven Findbugs Plugin in your own project by adding the following dependency: dependency groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.0-SNAPSHOT/version /dependency *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will require Maven to be run with a minimum of Java 5. This is consistent with Findbugs requirement for their versions of 1.3.X and greater. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Regards, Garvin LeClaire garvin.lecla...@gmail.com -- View this message in context: http://www.nabble.com/-Vote--findbugs-maven-plugin-v-2.0--release-tp22715803p22723449.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
Re: How to integrate xhtml files into a maven generated site?
This will just copy the xhtml file as a resource, so you can link it statically. With Doxia 1.1 you can have the xhtml source file processed by the site renderer, so it gets really integrated in the site, with navigation, menus, etc. -Lukas Manos Batsis wrote: Sorry if this is out of context, haven't followed the thread. For now the best way AFAIK is to just add (X)HTML files in src/site/resources and link as appropriate. hth, Manos - 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
Maven Stage Plugin issue
Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) I found this bug in Jira that is somewhat similar but is marked as closed/fixed: http://jira.codehaus.org/browse/MNG-3581 I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists. According to this bug: http://jira.codehaus.org/browse/MSTAGE-3 Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly probably because I don't know where to look. Was this tool not intended to be used on a local file systems? Thanks! -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Test built jar
If it doesn't make sense, what can I do (other than : created a project having a dependency on the to-be-tested project...) This sounds like the most sane and standard solution to the problem, given what you've said above. Or you could try binding an execution of m-jar-p to a phase earlier than package and before test, and then monkey with the Surefire parameters to it tests the jar instead of target/classes. But this sounds very non-standard and I'm not positive it would even work. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: multi-module pom: do something after build?
http://maven.apache.org/plugins/maven-invoker-plugin/examples/post-build-scr ipt.html -Original Message- From: news [mailto:n...@ger.gmane.org] On Behalf Of Kristian Rink Sent: Thursday, March 26, 2009 10:38 AM To: users@maven.apache.org Subject: multi-module pom: do something after build? Folks; maybe a strange question: At the moment I am dealing with a project containing several module/module's to be built, including a couple of .jar and a couple of .war artifacts. In order to have the .war artifacts (finalName.war) deployable to an application server, I want to configure my project to, after everything has been built, have all these .war files ($project/target/finalName.war) copied to an arbitrary folder somewhere in my file system (say, an autodeploy one). Is there a straightforward way getting this done? TIA and all the best, Kristian - 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: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 10:26 PM, Martin Gainty wrote: The only way to accomplish this is called version control I thought it was clear in the first paragraph that version control is involved: They have both checked out Foo's trunk and are regularly committing changes to it. There are several other indications as well, such as the description of Alice tagging the code base and Bob updating his working copy. To be absolutely clear, Alice and Bob are both using version control. All code, including AppA, AppB, and Foo are managed in a source code repository. But I don't think this improves the situation in any way. As Ben noted, the scenario shows version control working as designed. but since you do not want to use version control .. Why do you think this? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 3:26 PM, Martin Gainty wrote: someone is assigned mainline of code and someone-else assigned a branch (this happens when core is heavily customised for a customer's needs where the user-specific mods will be integrated by merge-branch later on) This does not solve Bob's problem. Assume that Bob is working on a branch of Foo. At some point he will A) merge the trunk's changes into his branch, or B) merge the branch into the trunk and then switch to the trunk. If this happens after Alice increments Foo's trunk to 2.2- SNAPSHOT, the problem will occur. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote: Bob should work on a branch. IMHO if any work is taking a long time and you can't commit it to trunk in a timely manner, then do that work on a branch so you can commit often and still take specific control over when Alice's changes get merged to Bob's branch so he can test the merge thoroughly before putting his changes in trunk. This does not solve Bob's problem. Let's say he's committing to his branch, and then at some point he merges Alice's changes to the trunk into his branch. He then performs thorough testing of this new code and encounters no problems. But of course he won't have any problems testing the new Foo 2.2-SNAPSHOT because AppB is still still using the old code from Foo 2.1-SNAPSHOT. Until he realizes that Foo's version has changed, and he updates AppB accordingly, branching, merging, and testing won't help him. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 5:28 PM, Brian E. Fox wrote: Do we assume that bob is unable to see that the version he currently works on and compiles, tests, installs and maybe deploys has 2.2-snapshot written all over it? Yes. Maven generates a lot of output to the console, and it's easy to ignore all the text that scrolls by. Even if the output were minimal, Bob is updating and rebuilding his working copy of Foo several times a day. He's not in the habit of examining the build output closely, at least not when the build succeeds, as in this scenario. Sure, he might notice the version change eventually, but perhaps not before he wastes a couple of hours debugging the problem. Also, consider that Foo may not be the only shared library that Bob's AppB depends on. There could be Bar, Bat, Baz, Xyzzy, and Thud as well. These libraries might be under active development too, and their versions may change periodically. With all these version numbers floating around, even if Bob notices that Foo is 2.2-SNAPSHOT today, he might have simply forgotten that it was 2.1-SNAPSHOT yesterday. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 5:07 PM, Sean Hennessy wrote: Evidence to the contrary that Bob and Alice are working independently is they share development on single artifact Foo. They're working independently on AppA and AppB, but they're sharing the work of developing Foo. Ensure Alice and Bob communicate daily on the development plan, schedule and status. Yes, that is true. Alice should have told Bob that she released Foo 2.1, and that development on the trunk is now at version 2.2-SNAPSHOT, and that Bob should update his AppB to depend on this new version. That would have definitely solved Bob's problem. But the side-effect is that whenever there's a new release of a dependency, emails must be sent and POM files must be updated. For Alice's and Bob's simple scenario, that's not a big deal. But consider a real-world scenario with many developers and perhaps dozens of interwoven dependencies. The stream of new releases causes a flurry of communication and lots of POM editing, especially if the development teams are following a release early, release often kind of strategy. The overhead is not scalable, especially in the face of human error. (An email could be forgotten, or a POM file could be updated with the wrong version number.) In fact, all this overhead encourages developers to *avoid* releasing new versions of dependencies. They want to work with X-SNAPSHOT for as long as possible simply to avoid the extra work of putting out a new version, even if it's just an internal release. (This is precisely the problem we're facing in my team and is what prompted the original post.) Of course, staying with a SNAPSHOT release for extended periods complicates regression testing and other quality assurance tasks. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Getting Assembly and Jar signer plugins to work together well
I'm trying to build a simple WebStart jar for deployment, and I've found that the Assembly plugin's capability of building an uber-jar with dependencies will work fine for our needs. I need to sign it since the app requires all permissions, but I'm having a little trouble getting the jar signer to work the way I want it to. It is signing the initial application code's jar before it is handled by Assembly to create the jar-with-dependencies jar. What I want it to do is wait until the assembly plugin assembles the big jar, and then sign that instead. Any suggestions on how I would go about doing that? -peter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
I don't think so. When Bob merges the trunk to branch he will have both Alice's changes and his. When he does an install, the 2.2-SNAPSHOT version will contain both his and Alices changes for all modules. --- Todd Thiessen -Original Message- From: Trevor Harmon [mailto:tre...@vocaro.com] Sent: Thursday, March 26, 2009 12:39 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote: Bob should work on a branch. IMHO if any work is taking a long time and you can't commit it to trunk in a timely manner, then do that work on a branch so you can commit often and still take specific control over when Alice's changes get merged to Bob's branch so he can test the merge thoroughly before putting his changes in trunk. This does not solve Bob's problem. Let's say he's committing to his branch, and then at some point he merges Alice's changes to the trunk into his branch. He then performs thorough testing of this new code and encounters no problems. But of course he won't have any problems testing the new Foo 2.2-SNAPSHOT because AppB is still still using the old code from Foo 2.1-SNAPSHOT. Until he realizes that Foo's version has changed, and he updates AppB accordingly, branching, merging, and testing won't help him. Trevor - 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 Stage Plugin issue
try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) I found this bug in Jira that is somewhat similar but is marked as closed/fixed: http://jira.codehaus.org/browse/MNG-3581 I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists. According to this bug: http://jira.codehaus.org/browse/MSTAGE-3 Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly probably because I don't know where to look. Was this tool not intended to be used on a local file systems? Thanks! -Jim - 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: Possible problem when multiple developers depend on SNAPSHOT versions
Yes he does need to know that the release has changed. This is something you would need to be aware of when you do the merge. --- Todd Thiessen -Original Message- From: Thiessen, Todd (BVW:9T16) Sent: Thursday, March 26, 2009 12:53 PM To: Maven Users List Subject: RE: Possible problem when multiple developers depend on SNAPSHOT versions I don't think so. When Bob merges the trunk to branch he will have both Alice's changes and his. When he does an install, the 2.2-SNAPSHOT version will contain both his and Alices changes for all modules. --- Todd Thiessen -Original Message- From: Trevor Harmon [mailto:tre...@vocaro.com] Sent: Thursday, March 26, 2009 12:39 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote: Bob should work on a branch. IMHO if any work is taking a long time and you can't commit it to trunk in a timely manner, then do that work on a branch so you can commit often and still take specific control over when Alice's changes get merged to Bob's branch so he can test the merge thoroughly before putting his changes in trunk. This does not solve Bob's problem. Let's say he's committing to his branch, and then at some point he merges Alice's changes to the trunk into his branch. He then performs thorough testing of this new code and encounters no problems. But of course he won't have any problems testing the new Foo 2.2-SNAPSHOT because AppB is still still using the old code from Foo 2.1-SNAPSHOT. Until he realizes that Foo's version has changed, and he updates AppB accordingly, branching, merging, and testing won't help him. Trevor - 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: hibernate byte code instrumentation
Try this:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
fachhoch wrote:
I did not understand this, please explain what should I change in pom to do
this ?
here is my jetty maven plugin
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version6.1.12.rc4/version
configuration
dependencies
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
version1.0.4/version
typejar/type
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.14/version
typejar/type
/dependency
/dependencies
/configuration
/plugin
here is my maven ant run plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
configuration
tasks
taskdef name=instrument
classname=org.hibernate.tool.instrument.javassist.InstrumentTask
classpath
path refid=maven.runtime.classpath /
path refid=maven.plugin.classpath /
/classpath
/taskdef
instrument verbose=true
fileset dir=${project.build.outputDirectory}
include name=**/model/**/*.class /
/fileset
/instrument
/tasks
/configuration
/plugin
please tell me what should I do to my pom to acheieve what you said .
Stephen Connolly-2 wrote:
attach the execution to the process-classes phase
2009/3/26 fachhoch fachh...@gmail.com
I am using maven-ant-run plugin to call hibernate byte code
insturmentation
, i also have maven jetty plugin , every time i run jetty plugin first
all modified java files gets complied and then test cases and finally
deployed , but this ant-run plugin for hibernate byte code
instrumentation
does not get called , please tell me how to call hibernate byte code
automatically ?
--
View this message in context:
http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22714675.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 Stage Plugin issue
Hi Dan, Thanks a lot for the response. I took a look at it and it definitely seems more full featured than the staging plugin, but I'm still having trouble with it. If I formulate a command like this: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://E:\dir\staging-repo -Dwagon.target=file://E:\dir\staging-repo1 I get this error: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect Did I miss understand the input parameters? I'm assuming that you are referring to this version of wagon-maven-plugin. http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1 I found what appears to be an older Apache MyFaces project by the same artifactId. -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 11:54 AM To: Maven Users List Subject: Re: Maven Stage Plugin issue try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) I found this bug in Jira that is somewhat similar but is marked as closed/fixed: http://jira.codehaus.org/browse/MNG-3581 I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists. According to this bug: http://jira.codehaus.org/browse/MSTAGE-3 Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly probably because I don't know where to look. Was this tool not intended to be used on a local file systems? Thanks! -Jim - 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 Stage Plugin issue
try file:///e:/dir/staging-repo -D On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hi Dan, Thanks a lot for the response. I took a look at it and it definitely seems more full featured than the staging plugin, but I'm still having trouble with it. If I formulate a command like this: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://E:\dir\staging-repo -Dwagon.target=file://E:\dir\staging-repo1 I get this error: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect Did I miss understand the input parameters? I'm assuming that you are referring to this version of wagon-maven-plugin. http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1 I found what appears to be an older Apache MyFaces project by the same artifactId. -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 11:54 AM To: Maven Users List Subject: Re: Maven Stage Plugin issue try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) I found this bug in Jira that is somewhat similar but is marked as closed/fixed: http://jira.codehaus.org/browse/MNG-3581 I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists. According to this bug: http://jira.codehaus.org/browse/MSTAGE-3 Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly probably because I don't know where to look. Was this tool not intended to be used on a local file systems? Thanks! -Jim - 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: Maven Stage Plugin issue
yes myface has this plugin too to serve what they need On Thu, Mar 26, 2009 at 11:31 AM, Dan Tran dant...@gmail.com wrote: try file:///e:/dir/staging-repo -D On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hi Dan, Thanks a lot for the response. I took a look at it and it definitely seems more full featured than the staging plugin, but I'm still having trouble with it. If I formulate a command like this: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://E:\dir\staging-repo -Dwagon.target=file://E:\dir\staging-repo1 I get this error: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect Did I miss understand the input parameters? I'm assuming that you are referring to this version of wagon-maven-plugin. http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1 I found what appears to be an older Apache MyFaces project by the same artifactId. -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 11:54 AM To: Maven Users List Subject: Re: Maven Stage Plugin issue try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) I found this bug in Jira that is somewhat similar but is marked as closed/fixed: http://jira.codehaus.org/browse/MNG-3581 I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists. According to this bug: http://jira.codehaus.org/browse/MSTAGE-3 Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly probably because I don't know where to look. Was this tool not intended to be used on a local file systems? Thanks! -Jim - 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: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 26, 2009, at 12:52 PM, Todd Thiessen wrote: I don't think so. When Bob merges the trunk to branch he will have both Alice's changes and his. When he does an install, the 2.2-SNAPSHOT version will contain both his and Alices changes for all modules. Yes, but AppB will still reference Foo 2.1-SNAPSHOT. Therein lies the problem. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven Stage Plugin issue
Hi Dan, Thanks again for the response. I tried a few variations on that theme: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:/dir/staging-repo -Dwagon.target=file:///e:/dir/staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:/dir/staging-repo -Dwagon.target=file://e:/dir/staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:\\dir\\staging-repo -Dwagon.target=file:///e:\\dir\\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\\dir\\staging-repo -Dwagon.target=file://e:\\dir\\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:\dir\staging-repo -Dwagon.target=file:///e:\dir\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\dir\staging-repo -Dwagon.target=file://e:\dir\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://./staging-repo -Dwagon.target=file://./staging-repo1 They all give me the same error message: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 1:32 PM To: Maven Users List Subject: Re: Maven Stage Plugin issue try file:///e:/dir/staging-repo -D On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hi Dan, Thanks a lot for the response. I took a look at it and it definitely seems more full featured than the staging plugin, but I'm still having trouble with it. If I formulate a command like this: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://E:\dir\staging-repo -Dwagon.target=file://E:\dir\staging-repo1 I get this error: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect Did I miss understand the input parameters? I'm assuming that you are referring to this version of wagon-maven-plugin. http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1 I found what appears to be an older Apache MyFaces project by the same artifactId. -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 11:54 AM To: Maven Users List Subject: Re: Maven Stage Plugin issue try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) I found this bug in Jira that is somewhat similar but is marked as closed/fixed: http://jira.codehaus.org/browse/MNG-3581 I have tried 2.0.10 and 2.1.0 as the bug suggests, but the problem persists. According to this bug: http://jira.codehaus.org/browse/MSTAGE-3 Some fix was put in for 1.0-alpha-2 but I can't find that anywhere, mostly probably because
RE: Maven Stage Plugin issue
All, I finally got it. I was missing the temp directory -Djava.io.tmpdir=target. mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\dir\staging-repo -Dwagon.target=file://e:\dir\staging-repo1 -Djava.io.tmpdir=target Needing that is not listed here: http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html But it is in the usage example here: http://mojo.codehaus.org/wagon-maven-plugin/usage.html Thanks for all the help! -Jim -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Thursday, March 26, 2009 1:49 PM To: 'Maven Users List' Subject: RE: Maven Stage Plugin issue Hi Dan, Thanks again for the response. I tried a few variations on that theme: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:/dir/staging-repo -Dwagon.target=file:///e:/dir/staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:/dir/staging-repo -Dwagon.target=file://e:/dir/staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:\\dir\\staging-repo -Dwagon.target=file:///e:\\dir\\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\\dir\\staging-repo -Dwagon.target=file://e:\\dir\\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:\dir\staging-repo -Dwagon.target=file:///e:\dir\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\dir\staging-repo -Dwagon.target=file://e:\dir\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://./staging-repo -Dwagon.target=file://./staging-repo1 They all give me the same error message: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 1:32 PM To: Maven Users List Subject: Re: Maven Stage Plugin issue try file:///e:/dir/staging-repo -D On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hi Dan, Thanks a lot for the response. I took a look at it and it definitely seems more full featured than the staging plugin, but I'm still having trouble with it. If I formulate a command like this: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://E:\dir\staging-repo -Dwagon.target=file://E:\dir\staging-repo1 I get this error: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect Did I miss understand the input parameters? I'm assuming that you are referring to this version of wagon-maven-plugin. http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1 I found what appears to be an older Apache MyFaces project by the same artifactId. -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 11:54 AM To: Maven Users List Subject: Re: Maven Stage Plugin issue try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) at org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) at
Maven release plugin issue- Error code 401
Hi, I am running maven perform and get the following error. I am the Nexus Administrator and I have commented out passwd in settings.xml in my local repo. What could be wrong here ? I want to use the release plugin only for deployments. [ERROR] BUILD ERROR [INFO] - --- [INFO] Error deploying artifact: Failed to transfer file: http://fpsvn00 1.na.coglobal.com:8081/nexus/content/repositories/releases/com/co/maven/co-m aven/1.0/co-maven-1.0.pom. Return code is: 401 Thanks, -- View this message in context: http://www.nabble.com/Maven-release-plugin-issue--Error-code-401-tp22729480p22729480.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
RE: Possible problem when multiple developers depend on SNAPSHOT versions
Yes, but AppB will still reference Foo 2.1-SNAPSHOT. Therein lies the problem. Trevor I guess I don't see that as a problem. Bob wants to merge in the latest version from trunk. If the version has been upped since Bob made his branch, he would need to know that. That is just the nature of versions. Its kind of like saying you want to use the latest version of log4j, get that version into your local repository but then forget to reference it in your pom. He could always get the latest version by not specifying any version but again this is usually frowned upon since it kind of negates all the benefits of having versions in the first place ;-). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release plugin issue- Error code 401
[INFO] Error deploying artifact: Failed to transfer file: http://fpsvn00 1.na.coglobal.com:8081/nexus/content/repositories/releases/com/co/maven/co-m aven/1.0/co-maven-1.0.pom. Return code is: 401 HTTP Error 401 is... Unauthorized, right? Solve that, and deploy will proceed. Check filesystem permissions etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Stage Plugin issue
glad it works out for you -Dan On Thu, Mar 26, 2009 at 12:16 PM, Jim McCaskey jim.mccas...@pervasive.com wrote: All, I finally got it. I was missing the temp directory -Djava.io.tmpdir=target. mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\dir\staging-repo -Dwagon.target=file://e:\dir\staging-repo1 -Djava.io.tmpdir=target Needing that is not listed here: http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html But it is in the usage example here: http://mojo.codehaus.org/wagon-maven-plugin/usage.html Thanks for all the help! -Jim -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Thursday, March 26, 2009 1:49 PM To: 'Maven Users List' Subject: RE: Maven Stage Plugin issue Hi Dan, Thanks again for the response. I tried a few variations on that theme: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:/dir/staging-repo -Dwagon.target=file:///e:/dir/staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:/dir/staging-repo -Dwagon.target=file://e:/dir/staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:\\dir\\staging-repo -Dwagon.target=file:///e:\\dir\\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\\dir\\staging-repo -Dwagon.target=file://e:\\dir\\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file:///e:\dir\staging-repo -Dwagon.target=file:///e:\dir\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://e:\dir\staging-repo -Dwagon.target=file://e:\dir\staging-repo1 mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://./staging-repo -Dwagon.target=file://./staging-repo1 They all give me the same error message: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 1:32 PM To: Maven Users List Subject: Re: Maven Stage Plugin issue try file:///e:/dir/staging-repo -D On Thu, Mar 26, 2009 at 11:23 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hi Dan, Thanks a lot for the response. I took a look at it and it definitely seems more full featured than the staging plugin, but I'm still having trouble with it. If I formulate a command like this: mvn org.codehaus.mojo:wagon-maven-plugin:1.0-beta-1:merge-maven-repos -Dwagon.source=file://E:\dir\staging-repo -Dwagon.target=file://E:\dir\staging-repo1 I get this error: [ERROR] BUILD ERROR [INFO] [INFO] Error during performing repository copy Embedded error: The filename, directory name, or volume label syntax is incorrect Did I miss understand the input parameters? I'm assuming that you are referring to this version of wagon-maven-plugin. http://mojo.codehaus.org/wagon-maven-plugin/merge-maven-repos-mojo.html http://repo1.maven.org/maven2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-1 I found what appears to be an older Apache MyFaces project by the same artifactId. -Jim -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Thursday, March 26, 2009 11:54 AM To: Maven Users List Subject: Re: Maven Stage Plugin issue try wagon-maven-plugin with maven 2.1.0 to see it works out for you. It has a port of maven-stage-plugin with lots of fixes. -D On Thu, Mar 26, 2009 at 8:36 AM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I am attempting to use the Maven stage plugin and running into a break. I have tried this using Maven 2.0.7, 2.0.8, 2.0.9, 2.0.10, and 2.1.0. I'm also using the only stage plugin available which appears to be 1.0-alpha-1. My guess is I'm doing something wrong, but for the life of me I can't see what. Here is the command I am executing (I'm on windows FWIW): mvn -Dsource=file://E:\dir\staging-repo -Dtarget=file://E:\dir\staging-repo1 -Dversion=9.2.0-16 stage:copy Here is the error: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.file.FileWagon [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.wagon.providers.file.FileWagon at
SCM requires that command line svn be used?
I'm trying to configure my pom to use an scm. We use Subversion. When I run it, I get the error 'svn' is not recognized as an internal or external command, operable program or batch file.. I take it this means that svn.exe needs to be on the path, and the plugin is shelling out to access it. This is obviously flaky and error prone. In Ant, I can use SvnAnt to access svn directly, using java alone. Is it possible to configure Maven to use one of the svn-java libraries instead of the command line client? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: SCM requires that command line svn be used?
Hi, It's possible with the javasvn implementation. This has been moved recently from the asf repository due to license issue. Now it's here : http://code.google.com/p/maven-scm-provider-svnjava/ It will be released after the maven-scm release. HTH, -- Olivier 2009/3/26 Chris she...@yahoo.com: I'm trying to configure my pom to use an scm. We use Subversion. When I run it, I get the error 'svn' is not recognized as an internal or external command, operable program or batch file.. I take it this means that svn.exe needs to be on the path, and the plugin is shelling out to access it. This is obviously flaky and error prone. In Ant, I can use SvnAnt to access svn directly, using java alone. Is it possible to configure Maven to use one of the svn-java libraries instead of the command line client? - 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-surefire-plugin: run unit tests from classes in a jar, not a directory
Thanks for your replies, Brett and Stephen! I was able to use the @RunWith with a Suite subclass that would search for unit tests within jars in the classpath. However, the problem with that approach is that all the unit tests run within the same JVM. Whereas we want all the unit tests to be forked, pretty much like forkMode=always. Looking through the code, it appears to me that I can write my own subclass of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override its locateTestSets() method (actually I just want to override collectTests() but that is private) to be able to implement my own test discovery algorithm. However, it's not clear to me how I can get surefire plugin to use my subclass instead of the Junit one. I guess I may have to create my own surefire-provider? I guess I can do that by starting with (or extending) the junit4 provider. Lets say I do that how, is there a way to get surefire to use my provider instead of junit 4. Cheers, Anshul On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal ans...@marketcetera.comwrote: Folks, The surefire plugin currently supports automatically searching for unit testing classes from a directory. I was wondering if there is way for it to search for unit tests from a set of jar files instead of a directory. ie., a mechanism where I can specify a regex pattern for the package and/or class name and it can search through all the jars in the 'test' scope for classes matching that pattern and run them. Thanks in advance! Anshul
Re: [maven-eclipse-plugin] and .aj AspectJ files.
Added http://jira.codehaus.org/browse/MECLIPSE-538. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Vote] findbugs-maven-plugin v 2.0 release
1.3.8 isn't in the central repo : http://repo1.maven.org/maven2/com/google/code/findbugs/findbugs/ Arnaud On Thu, Mar 26, 2009 at 3:43 PM, TM thorsten.moel...@unibas.ch wrote: -1 Background: According to http://jira.codehaus.org/browse/MFINDBUGS-66, the plugin integrates Findbugs version 1.3.6. Meanwhile, version 1.3.8 was released. I suggest to catch up with that release before releasing the plugin. -- Thorsten Garvin LeClaire-2 wrote: The Maven Findbugs team would like to release Maven Findbugs Plugin version 2.0 This plugin allows the developer to run Findbugs analysis against a Maven project and produce site output in HTML to match other site reports. There are option to produce other XML outputs which are used by other plugins. Issues fixed in this release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=14335pid=11701status=6sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC More information can be found at the plugin site: http://mojo.codehaus.org/findbugs-maven-plugin/ Issues Can be registered in JIRA at: http://jira.codehaus.org/browse/MFINDBUGS More information on FindBugs http://findbugs.sourceforge.net/index.html You can test the Maven Findbugs Plugin in your own project by adding the following dependency: dependency groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.0-SNAPSHOT/version /dependency *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will require Maven to be run with a minimum of Java 5. This is consistent with Findbugs requirement for their versions of 1.3.X and greater. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Regards, Garvin LeClaire garvin.lecla...@gmail.com -- View this message in context: http://www.nabble.com/-Vote--findbugs-maven-plugin-v-2.0--release-tp22715803p22723449.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 -- Arnaud
Re: Maven extra sources and eclipse
Did you write maven plugin to generate sources under target/generate-sources? If so you can maven plugin api to add these extra source directories to project. Jean-Marc Vanel-2 wrote: Hi all We have a projet ( http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/pom.xml ) using a parser generator , for which we have extra Java sources, not for building with the application. We generate the eclipse configuration with Maven, but I found no way to specify these extra Java sources so that they appear in the eclipse configuration. Thanks for any hint -- Jean-Marc Vanel Consulting, services, training, Rule-based programming, Semantic Web http://jmvanel.free.fr/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://www.nabble.com/Maven-extra-sources-and-eclipse-tp22719773p22733515.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
Ideal File Placement
Hello, In a multi-module maven project, a webapp module has java, resources and WEB-INF folders. In which folder should jsp, css, web.xml, spring XML configurations and other files go? -- Thank you, Sammy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Ideal File Placement
are you building a war or an ear if ear which AppServer will you deploy to? ? Martin __ Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. To: users@maven.apache.org From: pico...@gmail.com Subject: Ideal File Placement Date: Fri, 27 Mar 2009 01:57:35 +0200 Hello, In a multi-module maven project, a webapp module has java, resources and WEB-INF folders. In which folder should jsp, css, web.xml, spring XML configurations and other files go? -- Thank you, Sammy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Internet Explorer 8 – Get your Hotmail Accelerated. Download free! http://clk.atdmt.com/MRT/go/141323790/direct/01/
Grandparent classes not found at compile time
I'm confused about why transitive provided dependencies shouldn't be included at compile time. I have a project, myapp-web, which defines a custom Servlet, MyServlet. MyServlet extends a BaseServlet from framework. BaseServlet extends a Servlet class from thirdparty, ThirdPartyServlet. ThirdPartyServlet in turn implements the third party's CacheableServlet interface among other things. myapp-web: MyServlet framework: BaseServlet thirdparty: ThidrdPartyServlet, CacheableServlet, etc. So myapp's pom declares a compile-time dependency on framework, and framework declares a provided dependency on thirdparty. This is because the thirdparty jar is available at runtime in my container, thus I don't want to ever include it transitively for packaging. So when myapp-web compiles, it needs the definition of BaseServlet.class which it finds in its compile time dependency of framework. However, it seems to not know about the definitions of BaseServelt's parent class (MyServlet's grandparent class), ThirdPartyServlet. I get compile-time errors like these: MyServlet.java:[199,20] cannot find symbol symbol : variable this location: class com.myapp.MyServlet MyServlet.java:[201,24] cannot find symbol symbol : variable super location: class com.myapp.MyServlet Because MyServlet extends BaseServlet which extends ThirdPartyServlet, doesn't the compile NEED to know about all classes in the hierarchy in order to compile? Thus, I would think anything that was available at compile time during the building of BaseServlet COULD BE a compile-time dependency to dependents of framework (such as myapp-web). So why does Maven NOT include provided dependencies transitively at compile time? This is presently blocking me. My workaround is to explicitly add thirdparty as a provided dependency to myapp-web so that the ThirdPartyServlet and CacheableServlet definitions will be available at compile time. But this is the very thing that transitive dependencies solves for COMPILE dependencies (which are really COMPILED and PACKAGED). Why not solve it for TRANSITIVE dependencies (whcich are COMPILED but NOT PACKAGED). -- View this message in context: http://www.nabble.com/Grandparent-classes-not-found-at-compile-time-tp22733894p22733894.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
Re: [maven-eclipse-plugin] and .aj AspectJ files.
Can you confirm that src/main/aspect should be including=**/*.java|**/*.aj instead of just including=**/*.aj Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-eclipse-plugin] and .aj AspectJ files.
On Fri, Mar 27, 2009 at 12:19 PM, Barrie Treloar baerr...@gmail.com wrote: Can you confirm that src/main/aspect should be including=**/*.java|**/*.aj instead of just including=**/*.aj Thanks Ok after googling, I can find more than one project that has java files in src/main/aspect. Will go with that. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Apache maven snapshots repository root links are invalid
Thanks for pointing this out. It's actually a misconfig in the proxy rewrite rules. The /snapshots is actually a proxy of http://repository.apache.org/content/groups/snapshots and it looks like the reverse proxy rules are bunging up the url. I'll have to polish my rewrite-fu to get them worked out. -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Thursday, March 26, 2009 6:59 AM To: Maven Users List Subject: Apache maven snapshots repository root links are invalid Hello maven users, Links on http://repository.apache.org/snapshots are invalid, they are missing snapshots part. This is error only in the root of the repository, once in some directory e.g. http://repository.apache.org/snapshots/org;, links work well. It seems to be some sort of (nexus) configuration issue. Regards, Stevo.
RE: How to perform a deploy only
Running the full lifecycle is a fundamental of Maven, so this type of feature request is unlikely to gain traction. You should rather look at your build configuration to solve the problem, or as mentioned use a repo man that can help you out. -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 11:26 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only Thanks for the suggestion. I have been trying to avoid using repository managers for a number of reasons that are beyond the scope of this thread. I may have to break down eventually... I'm surprised no one has needed this sort of feature, or maybe they have and that's why Nexus has the features that it does. I was hoping to find a Maven native (whatever native means in a highly pluggable architecture) way to do this that would not take much additional work. mvn -DdoNothingButDeploy=true deploy That would be about perfect. :) Would this even be consider for an enhancement request if I opened it? Perhaps I am the only one interested in such a thing. Thanks! -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:55 PM To: Maven Users List Subject: RE: How to perform a deploy only Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-eclipse-plugin] and .aj AspectJ files.
On Fri, Mar 27, 2009 at 12:23 PM, Barrie Treloar baerr...@gmail.com wrote: On Fri, Mar 27, 2009 at 12:19 PM, Barrie Treloar baerr...@gmail.com wrote: Can you confirm that src/main/aspect should be including=**/*.java|**/*.aj instead of just including=**/*.aj Thanks Ok after googling, I can find more than one project that has java files in src/main/aspect. Will go with that. http://jira.codehaus.org/browse/MECLIPSE-538 closed. Patched on trunk. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Ideal File Placement
For a tomcat app I put them in src/main/webapp/WEB-INF (web.xml and spring config) src/main/webapp/WEB-INF/views (with spring's view resolver configured to use this) src/main/webapp/images src/main/webapp/css Whatever is in src/main/resources will end up in tomcat/webapps/myWebApp/WEB-INF/classes which puts it on the classpath. Sammy wrote: Hello, In a multi-module maven project, a webapp module has java, resources and WEB-INF folders. In which folder should jsp, css, web.xml, spring XML configurations and other files go? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory
I was able to get this to work by modifying the sure-fire plugin source. I updated AbstractDirectoryTestSuite.collectTests() to be protected. And I over-rode that method in JUnit4DirectoryTestSuite to list all the jars from the class path and search for unit tests within them adding the discovered unit tests to the list of collected tests. It does seem to work. I guess, if SurefirePlugin, exposed the name of junit4DirectoryTestSuite as a parameter, like it exposes the testNG and junit artifact names. I would have been able to accomplish this without needing any changes to the plugin codebase. In case it's useful for folks, here is the background on why I'm wanting to do this. I'm using this mechanism to be able to create patch projects/artifacts for artifacts that only include the source for classes that are updated for that patch. These patch projects designate the project/artifact being patched as a parent. The patch project only contains the sources and unit tests for functionality that has been modified / added in the patch. The jar generated by these projects only have the patched classes and I can apply this patch by placing this jar ahead of the actual artifact's jar, in the classpath, in an installation. Along with running the unit tests that I have created for the patch, I do want to be able to run all the unit tests for the project/artifact being patched, so that I can verify that the entire project continues to work, as expected, with the changes. Through this mechanism I have that ability. Ofcourse, the artifact being patched has to export it's to the maven repository, so that the patch project can depend on it, but that's easy. Cheers, Anshul On Thu, Mar 26, 2009 at 1:57 PM, Anshul Jaiswal ans...@marketcetera.comwrote: Thanks for your replies, Brett and Stephen! I was able to use the @RunWith with a Suite subclass that would search for unit tests within jars in the classpath. However, the problem with that approach is that all the unit tests run within the same JVM. Whereas we want all the unit tests to be forked, pretty much like forkMode=always. Looking through the code, it appears to me that I can write my own subclass of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override its locateTestSets() method (actually I just want to override collectTests() but that is private) to be able to implement my own test discovery algorithm. However, it's not clear to me how I can get surefire plugin to use my subclass instead of the Junit one. I guess I may have to create my own surefire-provider? I guess I can do that by starting with (or extending) the junit4 provider. Lets say I do that how, is there a way to get surefire to use my provider instead of junit 4. Cheers, Anshul On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal ans...@marketcetera.comwrote: Folks, The surefire plugin currently supports automatically searching for unit testing classes from a directory. I was wondering if there is way for it to search for unit tests from a set of jar files instead of a directory. ie., a mechanism where I can specify a regex pattern for the package and/or class name and it can search through all the jars in the 'test' scope for classes matching that pattern and run them. Thanks in advance! Anshul
