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
[2] https://jira.codehaus.org/browse/MRELEASE-516


Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly <[email protected]>:

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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to