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 Wed, 27 Mar 2013 22:05:26 GMT
    *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 <rfscholte@apache.org>
To: Maven Developers List <dev@maven.apache.org>
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
> <andrei.pozolotin@gmail.com>:
>
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


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