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:55:49 GMT
is there a way to designate local-aggregator poms as such? say, have
version = 0.0.0, since they are never released.

-------- 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 04:44:20 PM CDT
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message