Well I see a release root as being where there is a non-inherited SCM.... If there are changes since the last release (or no last release) then it *should*/*could* be released which is what that plugin reports.
More interesting to me would be if a child project defines SCM that is identical to the "effective" from the parent (or from the aggregator if it were a parent) then that should not be a release root... In short I am trying to find directories where it is intended that one runs the release plugin to release a chunk of the reactor. On Sunday, 24 March 2013, Robert Scholte wrote: > Hi Stephen, > > I've just checked your code. > Most interesting is our difference of the definition "releaseRoot" (or in > my case rootProject, I think we mean the same thing with it). > If I'm correct you base it on the existence of the <scm>-section and if it > has ever been released (assuming a specific scm comment). > MRELEASE-814[1] is probably a good example for which this strategy won't > work. > I try to base it on the parent/module relationship. > > Although this looks close related to MRELEASE-516[2] it is actually a > complete other issue. > The problem I have with MRELEASE-516 is that it's not the "plug-and-play" > behavior you'd like to have, > which means that the developer is responsible for checking out separate > projects in the right structure. > > Robert > > [1] > https://jira.codehaus.org/**browse/MRELEASE-814<https://jira.codehaus.org/browse/MRELEASE-814> > [2] > https://jira.codehaus.org/**browse/MRELEASE-516<https://jira.codehaus.org/browse/MRELEASE-516> > > > Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly < > stephen.alan.conno...@gmail.com>: > > Hey one and all, >> >> So we all know how multiple projects with multiple release roots are a >> pain... >> >> Here's some experiments I've been playing with... >> >> Not yet brave enough to have it fire up release:prepare release:perform on >> each release root, nor fire up versions:set on the downstream projects >> with >> explicit dependencies, nor lather rinse repeat until there is nothing >> needing a release... >> >> But even the simple report should be useful, and if anyone has suggestions >> to help improve its recommendations towards getting confidence that the >> automated stuff could work... please give me pull requests. >> >> If this proves useful, I will probably roll it into the release plugin... >> but for now I'll keep it in a holding pattern on github (where it is not >> in >> a default plugin groupId and hence relocation is less of an issue if I do >> happen to make any releases into central) >> >> $ mvn com.github.stephenc.maven:mpr-**maven-plugin:list-roots >> >> from an aggregator pom should identify all the release roots and whether >> they might need a release >> >> -Stephen >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
