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:07:51 GMT
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


Mime
View raw message