@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.pozolo...@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.conno...@gmail.com>
To: Andrei Pozolotin <andrei.pozolo...@gmail.com>
Cc: Maven Developers List <dev@maven.apache.org>, Robert Scholte
<rfscho...@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.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
--
Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
