Maintaining versions in a multi-module project
I am working on a multi-module project where I see that some of the module POMs have versions different from the parent POM. Apparently, developers have made changes to some of the modules and updated the version of only those modules. I also see another project where irrespective of which modules have been modified, developers modify the versions of all modules using mvn versions command to keep all of them in-sync. I am new to maven and have started using it only since last six months. Seeing the above mentioned two projects, I am confused what is the right path to take - updating all module versions irrespective of where changes are, or updating only those module versions where something changed. Thanks, Anuj Agrawal
Re: Maintaining versions in a multi-module project
Use whatever works best for you. I have some projects where it is better for me to force them all in lock-step I have other projects where I let them run free. My general rule of thumb: if the modules are in the same GIT repo or the same Subversion trunk then they all will end up being released as one atomic group, so keep the version numbers in sync. If they are in different SCM instances then they will be released independently so let them run free On 11 September 2014 09:35, Anuj Agrawal anujagrawa...@gmail.com wrote: I am working on a multi-module project where I see that some of the module POMs have versions different from the parent POM. Apparently, developers have made changes to some of the modules and updated the version of only those modules. I also see another project where irrespective of which modules have been modified, developers modify the versions of all modules using mvn versions command to keep all of them in-sync. I am new to maven and have started using it only since last six months. Seeing the above mentioned two projects, I am confused what is the right path to take - updating all module versions irrespective of where changes are, or updating only those module versions where something changed. Thanks, Anuj Agrawal
m-remote-resources-p mvn 3.2.1 vs mvn 3.2.3
m-remote-resources-p:process has serious bug with excludeTransitive option: * with maven 3.2.1 excludeTransitive=false, my build completes in about 10 seconds * with maven 3.2.3 excludeTransitive=false, my build dies with OOME after about 2 minutes * with maven 3.2.3 excludeTransitive=true, my build completes in about 10 seconds Anyone else seeing this? It looks like it was introduced in v1.5 because of http://jira.codehaus.org/browse/MRRESOURCES-58 -- look at the patch that was applied, the logic behind 'if ( this.excludeTransitive )' looks to be exactly wrong. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-surefire-plugin does not fail build if TestNG and JUnit47 are used
I have a module where maven-surefire-plugin (2.10) is configured to use TestNG and JUnit47. The former has several tests that all succeed and the later has two tests that fail. However the build succeeds. How can I configure surefire so the build fails if either have failures which is the expected behavior?
jarsigner plugin: specifying multiple arguments on the CLI
Apologies if this has been answered before. I don't see an entry in the plugin page's FAQ and find it with a quick Google search. I am behind a proxy so in order to specify a TSA I need to use -J-Dhttp.proxyHost=host -J-Dhttp.proxyPort=port as arguments. If I use -Djarsigner.arguments=... then it seems to enclose the whole value in single quotes on the exec'ed jarsign command, and soe the command fails. If I specify the two arguments in my pom (as an array), it works. So how do I specify multiple arguments on the command line? -- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
[ANN] Apache Maven RAR Plugin Version 2.4 Released
The Apache Maven team is pleased to announce the release of the Apache Maven RAR Plugin, Version 2.4 A resource adapter is a system-level software driver that a Java application uses to connect to an enterprise information system (EIS). The RAR plugin has the capability to store these resource adapters to an archive (Resource Adapter Archive or RAR) which can be deployed to a J2EE server. http://maven.apache.org/plugins/maven-rar-plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-rar-plugin/artifactId version2.4/version /plugin Release Notes - Apache Maven RAR Version 2.4 Improvements: * [MRAR-28] - Add Support for Classifier * [MRAR-35] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MRAR-37] - Upgrade maven-filtering to 1.2 * [MRAR-38] - Upgrade to Maven 2.2.1 compatiblity New Feature: * [MRAR-34] - provide skip parameter for the plugin Enjoy, -The Apache Maven team Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Tell maven to not have the parent pom as a dependency?
I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
Move it out as a stand alone project. -D On Thu, Sep 11, 2014 at 8:25 PM, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Maintaining versions in a multi-module project
I use the maven versions plugin for this… I just run: mvn versions:set -DnewVersion=0.0.3 mvn versions:commit and all my pom.s are updated. On Thu, Sep 11, 2014 at 6:02 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Use whatever works best for you. I have some projects where it is better for me to force them all in lock-step I have other projects where I let them run free. My general rule of thumb: if the modules are in the same GIT repo or the same Subversion trunk then they all will end up being released as one atomic group, so keep the version numbers in sync. If they are in different SCM instances then they will be released independently so let them run free On 11 September 2014 09:35, Anuj Agrawal anujagrawa...@gmail.com wrote: I am working on a multi-module project where I see that some of the module POMs have versions different from the parent POM. Apparently, developers have made changes to some of the modules and updated the version of only those modules. I also see another project where irrespective of which modules have been modified, developers modify the versions of all modules using mvn versions command to keep all of them in-sync. I am new to maven and have started using it only since last six months. Seeing the above mentioned two projects, I am confused what is the right path to take - updating all module versions irrespective of where changes are, or updating only those module versions where something changed. Thanks, Anuj Agrawal -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
Re: Tell maven to not have the parent pom as a dependency?
On 12 September 2014 12:55, Kevin Burton bur...@spinn3r.com wrote: I have an OSS module in a multi-module maven project. I want to post this to a public repo… it’s open source. The problem is that the parent module is not OSS. When I setup a dependency it pulls in my OSS module just fine, but then it tries to pull down the parent module, which isn’t in the repo, and breaks. The parent pom isn’t really a dependency… so I’d like it to not need it is this possible? As Dan says, make it a stand alone project. i.e. Dont make it a module. Being a module has a special meaning - treat this as part of a bigger whole. It also help with syntatic sugar by allowing you to run one command at the top and have it propogate into all the modules. To be complete a module has nothing to do with dependencies or dependency management. The reason your OSS module is pulling in the parent is not because of dependency, but because of inheritance of the parent hierarchy. Usually all modules are released together and will share version identifiers. If they are released independently then you normally wont make them modules, and their version identifiers can do their own thing. There is a recent post Maintaining versions in a multi-module project that Stephen answers, you might also want to search the archives on this topic as well. A parent pom can be used in two ways; 1) to share common information i.e. inheritance 2) keep related artifacts together to make working on a bug that traverses artifacts easier i.e aggregation In your case I dont think you need to use aggregation, you just need to pull out the OSS artifact into its own stand alone location and then include it as a normal dependency in your non-OSS project. If you find that you are also fixing bugs in the OSS project at the same time you are working on the non-OSS one, then you might want to create an aggregate pom that has two modules (one OSS, the other non-OSS) so that you can run maven commands in one place against both projects. Stephen Connolly has some stuff somewhere about that I think. The freely availble Maven books might also go into this in more detail, but it tends to be a more advanced feature not well described. Cheers Barrie
