is there a way to designate local-aggregator poms as such? say, have version = 0.0.0, since they are never released.
-------- 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 04:44:20 PM CDT > Let me answer my own question: no, it is not the same. > Main difference is that your release-trees are correct, which is not > the case for MRELEASE-516. > The local-aggregator makes the difference. > I still have my doubts if the suggested solution is solid enough. > Maybe it is not the collection of release-roots we need to find, but > only the local-aggregator(s). All its modules are or should be > release-roots by definition. > Can we assume that the root-pom is the only local-aggregator or could > one of its modules also be a local-aggregator? > Can we assume that local-aggregators are never checked in? > > In the past I've had good discussions with Fred Cooke about > multi-modules in combination with the maven-release-plugin, so after > sharing some thoughts over the IRC-chat I asked him to join this thread. > > Robert > > Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte > <rfscho...@apache.org>: > >> So you actually are talking about >> https://jira.codehaus.org/browse/MRELEASE-516 ? >> >> Robert >> >> Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly >> <stephen.alan.conno...@gmail.com>: >> >>> 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 >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
