[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42975 ]
Brett Porter commented on MNG-521: ---------------------------------- my suggestions here: - let's keep the parent versioning simple, so use SNAPSHOT when not specified, or the version given when it is specified. search order: * use the reactor cache. If the POM is present, it is good to use for SNAPSHOT (but if a version is in the parent, then that is used from the repository, not the cache) * use the universal source directory. By default, SNAPSHOT if not in the cache comes from "../pom.xml", but we can allow the specification of <relativePath/> in the <parent> element which is used for this scenario only. I expect we might in the future deprecate this in favour of having a workspace definition that lets you map out all your checkouts and defaults to the USD layout. * use the repository to find the actual SNAPSHOT version This facilitates both the inherited and specified versions in subprojects in all scenarios, and the only possible inconsistency is checking out a project in isolation where it expects a POM from HEAD which is not in the repository. I would expect in this case to have CI taking care of publishing snapshots anyway. Note we are using SNAPSHOT, not RELEASE as this matches the "latest source code" more closely. The problem we will encounter is that this doesn't support branched development very well. I think we should work on that separately, and must come back to specifying an actual branch name rather than using the version to indicate it. We can do this in the 2.1 timeframe. When it comes time to produce a release, the release is run from the top level and everything is released together (the top level being the common base for tagging). If subprojects have their own release schedule then they will have their own trunk and tags and they will be released individually first (eg plugins). The release mojo needs to work in an aggregated fashion, so when run from the top it only tags once and then processes each subproject to update the POM (resolving the empty SNAPSHOT parent version to the published version which is shared, as well as any dependency references that match other projects in the reactor). Each subproject would then end up with the new version. The perform of the release would run its set of goals over each project in order from the tag as it does now. > 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]
