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 < > [email protected]>: > > 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 < > [email protected]>: > > 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<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 <[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 > > -- Sent from my phone
