maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Multi-project releases
Date Sun, 24 Mar 2013 22:55:56 GMT
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
>
>

-- 
Sent from my phone

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