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:56:57 GMT
sharing is a key. I suggest you change your assumption to have
aggregation pom be part of the source repo

-------- Original Message --------
Subject: Re: Multi-project releases
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Date: Sun 24 Mar 2013 05:55:56 PM CDT
> I usually don't check them in, but they can be useful for others, so not a
> valid assumption, also I do tend to layer them as the scope if a change
> grows.
>
> On Sunday, 24 March 2013, Robert Scholte wrote:
>
>> 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 <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<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<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
>>
>>


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