Yes I need to grök the fake SCM that people use for integration tests On Wednesday, 27 March 2013, Robert Scholte wrote:
> @Andrei, > > I've taken a look at your project and I think I understand what you're > trying to do with the maven-cascade-release-plugin. It requires a > non-chained project structure, that's not an option for us. > If these local-aggregators can be under source control and if they can be > layered we have a different challenge. > Stephen, I can give my thoughts a try by forking your plugin, but it's > missing tests. > > Robert > > > Op Mon, 25 Mar 2013 00:50:16 +0100 schreef Andrei Pozolotin < > [email protected]>: > > 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<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 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<https://jira.codehaus.org/browse/MRELEASE-814> >>>>> [2] >>>>> https://jira.codehaus.org/**browse/MRELEASE-516<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 >>> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Sent from my phone
