maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Multi-project releases
Date Sun, 24 Mar 2013 21:44:20 GMT
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  
<rfscholte@apache.org>:

> So you actually are talking about  
> https://jira.codehaus.org/browse/MRELEASE-516 ?
>
> Robert
>
> Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly  
> <stephen.alan.connolly@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.connolly@gmail.com><javascript:_e({}, 'cvml',  
>>> 'stephen.alan.connolly@gmail.com');>
>>> To: Andrei Pozolotin <andrei.pozolotin@gmail.com> <javascript:_e({},
>>> 'cvml', 'andrei.pozolotin@gmail.com');>
>>> Cc: Maven Developers List <dev@maven.apache.org> <javascript:_e({},
>>> 'cvml', 'dev@maven.apache.org');>, Robert Scholte  
>>> <rfscholte@apache.org><javascript:_e({}, 'cvml',  
>>> 'rfscholte@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 <rfscholte@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
>>> 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.connolly@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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message