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.conno...@gmail.com><javascript:_e({}, 'cvml',
'stephen.alan.conno...@gmail.com');>
To: Andrei Pozolotin <andrei.pozolo...@gmail.com> <javascript:_e({},
'cvml', 'andrei.pozolo...@gmail.com');>
Cc: Maven Developers List <dev@maven.apache.org> <javascript:_e({},
'cvml', 'dev@maven.apache.org');>, Robert Scholte
<rfscho...@apache.org><javascript:_e({}, 'cvml',
'rfscho...@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 <rfscho...@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.conno...@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
