There is a trick called the "local aggregator pom" that advanced users
employ.
You create a local only pom and list as modules all the projects you are
working on.
Each of those checked out projects are "release roots" if they are the root
of a multi-module release.
The local only pom allows within reactor resolution of dependencies so as
soon as you make changes to a module, the rest if the modules in the
reactor can pick them up (by linking in -snapshot dependencies)
Now when it comes time to release from such a local aggregator, you need to
find out which ones you've made changes on and release each one in turn,
perhaps upping within reactor dependencies as you go.
Some of the locale modules could be in git, some in svn, some in HG, etc.
but each release root has all its child modules in the one SCM root and
part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
> you are right, I am not: "You are not getting my plan" :-)
> * please define what you mean by "release root"?
> * can release root contain other release roots as modules?
> * can I release the release root w/o releasing the release root modules?
> (need a better term :-))
> * can your envisioned plugin automatically recursively release all other
> dependencies moving upward in the reactor dependency tree?
>
> -------- Original Message --------
> Subject: Re: Multi-project releases
> From: Stephen Connolly <stephen.alan.conno...@gmail.com><javascript:_e({},
> 'cvml', 'stephen.alan.conno...@gmail.com');>
> To: Andrei Pozolotin <andrei.pozolo...@gmail.com> <javascript:_e({},
> 'cvml', 'andrei.pozolo...@gmail.com');>
> Cc: Maven Developers List <dev@maven.apache.org> <javascript:_e({},
> 'cvml', 'dev@maven.apache.org');>, Robert Scholte
> <rfscho...@apache.org><javascript:_e({}, 'cvml', 'rfscho...@apache.org');>
> Date: Sun 24 Mar 2013 02:32:39 PM CDT
>
>
>
> On Sunday, 24 March 2013, Andrei Pozolotin wrote:
>
> Robert, Stephen:
>
> 1) from my experience "release root / top-to-bottom / monolithic " is a
> wrong approach.
> please consider instead "start-from-any-module / from-bottom-up /
> incremental" approach, as implemented here:
> https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
>
>
> You are not getting my plan.
>
> The plugin I envision will allow picking a release root from the
> reactor's set of release roots (suggesting which ones need a release) and
> then run release on that one.
>
> You then iterate until it says all done or you have released what you
> need
>
> No Big Bang from my PoV
>
>
>
>
> 2) it would be good to have some wiki page somewhere to flesh out all
> assumptions that currently go into release
> as well as to list the use cases people really need. here is one of my use
> cases:
>
> https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: Multi-project releases
> From: Robert Scholte <rfscho...@apache.org>
> To: Maven Developers List <dev@maven.apache.org>
> Date: Sun 24 Mar 2013 09:42:27 AM CDT
>
> 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
> <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
>
>
--
Sent from my phone
