-N Same for other operations to not recurse into children/modules.
On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin < andrei.pozolo...@gmail.com> wrote: > *Robert* > > unrelated question, may be you can clarify: in the current > maven-release-plugin > what is the way to release parent w/o releasing its modules? > > Thank you, > > Andrei > > -------- Original Message -------- > Subject: Re: Multi-project releases > From: Robert Scholte <rfscho...@apache.org> > To: Maven Developers List <dev@maven.apache.org>, Andrei Pozolotin > <andrei.pozolo...@gmail.com> > Cc: "Stephen Connolly" <stephen.alan.conno...@gmail.com> > Date: Sun 24 Mar 2013 11:36:04 AM CDT > > 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 > >>> > >>> > > > >