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> To: Andrei Pozolotin <andrei.pozolo...@gmail.com> Cc: Maven Developers List <dev@maven.apache.org>, Robert Scholte <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> <javascript:_e({}, > 'cvml', 'rfscho...@apache.org');> > To: Maven Developers List <dev@maven.apache.org> > <javascript:_e({}, 'cvml', '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> <javascript:_e({}, 'cvml', >> '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 release >>> plugin... >>> but for now I'll keep it in a holding pattern on github (where >>> it is not in >>> a default plugin groupId and hence relocation is less of an >>> issue if I do >>> happen to make any releases into central) >>> >>> $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots >>> >>> from an aggregator pom should identify all the release roots and >>> whether >>> they might need a release >>> >>> -Stephen >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> <javascript:_e({}, 'cvml', 'dev-unsubscr...@maven.apache.org');> >> For additional commands, e-mail: dev-h...@maven.apache.org >> <javascript:_e({}, 'cvml', 'dev-h...@maven.apache.org');> >> >> > > > > > > -- > Sent from my phone
