[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42886 ]
John Casey commented on MNG-521: -------------------------------- I want to mention that this proposed feature doesn't preclude doing exactly that with versions - maintaining a separate version for each subproject, and using a plugin to upgrade the version when you want. However, I personally (and I think a few will agree) feel that falling back to tool support is sort of a crutch...that is, if this is a use case that we determine to be reasonably common, then the build should support it natively. In the case of an EAR, where the EAR is the distribution atom, that is where the versioning is applied, and versions of subprojects don't really have much meaning. If you're going to develop and release an EAR on a single cycle, then it also makes sense to version it all at once. If you're going to version the entire EAR at once, then it simply doesn't make sense to have multiple version specifications inside that EAR...it is duplication of a single piece of information, and will lead to synchronicity problems (one being updated but not another). > 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]
