[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42889 ]
John Casey commented on MNG-521: -------------------------------- WRT the the ../pom.xml file-path thing: I can't believe I've missed this for so long, but there should be no reason that we cannot use the pom cache to lookup the groupId:artifactId from anywhere inside the scanned hierarchy (the reactorized project structure) and pull the version from the first ancestor that specifies it. If that parent doesn't exist in the scanned cache, then we fail with an error to checkout the rest of the project... This would help the Eclipse guys, since you could put your parent-pom in a project that is a sibling of the child-projects, and execute the build from the commen parent directory... HOWEVER, it seems that this whole approach of resolving the version without using a repository may cause problems for Continuum. In some cases, it might be desirable to add pieces of this type of project hierarchy to Continuum. If it doesn't checkout the whole project hierarchy, it cannot resolve the version of the parent - or the current project, I guess... > 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]
