OK, here are my thoughts. I tend not use use the aggregator pom as the parent pom.
I have a structure like: aggregator-pom + parent-pom + child-jar + child-jar etc. The aggregator uses parent-pom as it's parent too. You need to override some of the URLs as inheritance expects parent-child to be parents and childs. That allows me to release the suite by releasing from the aggregator pom, and release each module independently (by running release in the child module) I use mvn versions:update-parent to ensure that a release of just the parent is picked up by all children. Another option I see is to define the modules in a profile that is active by default, and have the release plugin configured not to use that profile. Saves the comment/uncomment if you want 2008/12/5 jallen <[EMAIL PROTECTED]> > > Aggregators do not need to be the parent of their modules yet the release > plugin assumes that all projects in the reactor are equal, for instance in > terms of the checking for SNAPSHOTs etc. Yet as a rule, being simple humans > we tend to inhert from the project above us. > > However doing so means you are scuppered when it comes to wanting to do > releases. > > The maven-plugins as a good example. However what does that mean when we > want to release this kind parent? Well the way release plugin works all the > child projects (actually not just childs, all projects in the reactor), > which in this example are all individual releasable products in their own > right, are all in non-SNAPSHOT states. But of course I don't want to > release > all those sub-modules too, they're on their own release cycles after all, > I'm just trying to release the parent. The parent doesnt depend on the > children its the other way round. And of course the majority of those > sub-modules (the plugins) actually inherit from older versions of the > parent > anyway and therefore have no relationship to the specific version we're > releasing. So how do i get round this? > > I think the maven team comment out the <modules> section of maven-plugins > project before they do a release of it and then add it back in after, yet > SVN tags the folder hierarchy and pulls in the sub-projects. This all seems > a bit off to me (more than a bit tbh), the confluence of these various > domains (maven coords, scm hierarchy, aggregators and reactor assumptions) > is very confusing. > > How about if i don't inherit from the containing project and instead > inherit > from a corp pom instead. Well still got the same problem as release is > looking at all projects in the reactor, not in the project hierarchy for > issues. > > There seems to be no way to tell release to ignore certain modules, as they > is with the site plugin. I think there used to be some kind of global mvn > 'exlcudeProjectsFromReactor' CLI option but i have not found any docs on > it. > The only thing i can think to do is either comment out the <modules> > section > in the parent, which is bizzare as I am changing its definition just before > a release then changing it back, not what i normally associate as an act of > releasing, not to mention the fact that the site that I will produce as > aprt of the release process will have no of its <modules> (i.e. in the > modules menu) or alternatively run the release plugin with -N, no reactor > mode. > > Note this is a very different scenario to a product release that is made of > non-independent sub-modules, there you can only release the whole thjing, > the sub-modules tend to inherit the parent's version number and even if you > made no changes to a particular sub-component between product releases, you > would still bump its version up. i.e. If it helps think JIRA, in this > example the product is the same as JIRA project and the maven sub-modules > are equivalent to JIRA components within that project. > > However the maven-plugins example is not the same as that product example. > Each plugin is a product (has its own JIRA project and release cycle), but > we still want them all to be built by a convienent mvn install in the > parent > directory and we would still like to inherit some settings from that common > parent. None of which seems possible. > > Please someone provide some guidance. I have the unenviable task of having > to sell maven to new organisation (again) and I can not hide this stuff two > times over. > > Cheers, > John > -- > View this message in context: > http://www.nabble.com/why-does-a-release-consider-all-the-projects-in-the-reactor-rather-than-just-those-in-the-hierarchy-tp20857618p20857618.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
