-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
> >>>
> >>>
> >
>
>

Reply via email to