*Robert:*
I actually relaxed "no module nesting" requirement. just not tested
well yet.
Thank you,
Andrei
-------- Original Message --------
Subject: Re: Multi-project releases
From: Robert Scholte <[email protected]>
To: Maven Developers List <[email protected]>
Date: Wed 27 Mar 2013 03:59:42 PM CDT
> @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
>>>>
>>>>
>>>> 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 <[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
>>>>> [2] 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]
>
>
