maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Pozolotin <andrei.pozolo...@gmail.com>
Subject Re: Multi-project releases
Date Sun, 24 Mar 2013 23:50:16 GMT
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 <stephen.alan.connolly@gmail.com>
To: Andrei Pozolotin <andrei.pozolotin@gmail.com>
Cc: Maven Developers List <dev@maven.apache.org>, Robert Scholte
<rfscholte@apache.org>
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 <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 
>>
>
>
> -- 
> Sent from my phone


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message