[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42977 ]
Brett Porter commented on MNG-521: ---------------------------------- *tweak last comment* For consistency will require that you specify the parent version and let the tools take care of updating it at release time. The matching version will still be located using the reactor and USD though. So: <parent> ... <version>1.2-SNAPSHOT</version> </parent> where parent has <version>1.2-SNAPSHOT</version> These get bumped up to 1.2 together, committed and tagged, and then all updated to 1.3-SNAPSHOT. This facilitates branch development in the fashion that we have it now, though I still don't think it is sophisticated enough to do too much concurrent development. I'm thinking that you either version everything the same, or you release each independantly you can still do an intermediate release of a child later if it fits your deployment mechanism but then the next one pulls them all back to the shared product version > Version inheritance from the parent pom > --------------------------------------- > > Key: MNG-521 > URL: http://jira.codehaus.org/browse/MNG-521 > Project: Maven 2 > Type: Improvement > Components: design > Reporter: Eugene Kuleshov > Assignee: John Casey > Fix For: 2.0-beta-1 > > > Currently m2 pom require to have explicit version of the parent pom in all > submodules. This should work fine for "standalone" artifacts. However there > is different type of projects (e.g. EAR) that is usually stored in version > control as a whole thing and may contain multiple modules (ejb jars, rar, > war, etc) that are build with the same version as entire EAR. So, EAR > application released with a single global version for all submodules. In m1 > this was possible to specify relative path to parent pom and use version > substitution in child modules and deployer goal was substituting values for > version numbers upon deployment. > For this kind of modules it is very important to have single palce that will > have global version number, which then used for submodules. It is also make > sense to kee optional relative path (that can be also removed/replaced with > concrete parent id/version upon deployment) to support local build. I believe > this is very important for J2EE builds as well as any other projects that are > releasing multiple artifacts/jars under the same version (e.g. ASM, XDoclet). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
