Andrei,
First of all I'm only talking about the definition of root project, not
about release stuff yet, because this has already consequences for other
plugins as well.
Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
should see that it does match your "start-from-any-module".
If this will be the component for plugins (and maybe other projects) which
contains the actual definitions and transformations, we have a good place
to document it and to refer to.
Robert
[1]
http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup&#l39
Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
<andrei.pozolo...@gmail.com>:
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
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 release
plugin...
but for now I'll keep it in a holding pattern on github (where it is
not in
a default plugin groupId and hence relocation is less of an issue if
I do
happen to make any releases into central)
$ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots
from an aggregator pom should identify all the release roots and
whether
they might need a release
-Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
