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]
