got it, thank you. this is the problem I have solved with my jenkins plugin.
there your "release root" goes by the name of "layout project". I also go 2 steps further: 1) I require that there are no <module> declarations in non-root projects, so all modules and parents are independent. 2) I do recursive release of the whole layout automatically, from any point in the middle tree, releasing what needs be released. -------- Original Message -------- Subject: Re: Multi-project releases From: Stephen Connolly <[email protected]> To: Andrei Pozolotin <[email protected]> Cc: Maven Developers List <[email protected]>, Robert Scholte <[email protected]> Date: Sun 24 Mar 2013 03:59:40 PM CDT > 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 <[email protected]> > <javascript:_e({}, 'cvml', '[email protected]');> > To: Andrei Pozolotin <[email protected]> > <javascript:_e({}, 'cvml', '[email protected]');> > Cc: Maven Developers List <[email protected]> > <javascript:_e({}, 'cvml', '[email protected]');>, Robert > Scholte <[email protected]> <javascript:_e({}, 'cvml', > '[email protected]');> > 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 <[email protected]> >> To: Maven Developers List <[email protected]> >> 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 >>> <[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 >> > > > -- > Sent from my phone
