sharing is a key. I suggest you change your assumption to have aggregation pom be part of the source repo
-------- Original Message -------- Subject: Re: Multi-project releases From: Stephen Connolly <stephen.alan.conno...@gmail.com> To: Maven Developers List <dev@maven.apache.org> Date: Sun 24 Mar 2013 05:55:56 PM CDT > I usually don't check them in, but they can be useful for others, so not a > valid assumption, also I do tend to layer them as the scope if a change > grows. > > On Sunday, 24 March 2013, Robert Scholte wrote: > >> 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 <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<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<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 >> >>
