[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42845 ]
John Casey commented on MNG-521: -------------------------------- With that last comment, I assume you're talking about resolving the parent-pom's version from the repository if it's not present. If we do that, what metadata will we use to resolve this? SNAPSHOT (and if so, which XX for XX-SNAPSHOT?), or RELEASE? The problem I can see with this is that it could lead to inconsistent builds, which isn't only a problem with releases, but with integration tests, test deployments resulting from these builds, and even developer builds. If a developer builds one of these subprojects using dependencies resolved from the last RELEASE of a parent-pom, and there is a newer version of the parent-pom in SCM which is meant to be used, it could lead to strange runtime errors in the resulting artifact. If we go down the path of allowing the parent-pom to set all version information for the entire hierarchy, then this becomes even more suspect, since we'd be setting the entire build's version information based on a parent-pom we resolved from the repository. I do think I'm in the minority on this side, but I am emphatically against using the repository for the parent-pom. If it's missing, it's dangerous to do anything but fail and prompt the user to checkout the whole project hierarchy. Inconsistencies like this will lead m2 to be misused and seen as low quality as a result of this abuse (it's unfair, but it's true). Is it really that onerous to say that the whole project hierarchy has to be in your work directory if you're using this type of multi-project? Is there a compelling reason to go to the repository for this information, or is this just an effort to go that extra mile and help users do weird things? > 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]
