I am not aware of a Maven feature to fully ignore them other than -N with the tag caveat. When I've done what you asked, I did not miss a Maven feature to do so. You could temporarily move the module dirs or release the parent in a new location without the modules (-N is still your friend to accomplish that so Maven does not try to process the listed modules). Depending how you release (e.g. manually, via CI job), having a release area separate from the dev area is a good idea anyway to prevent hassles with your dev work (while release plugin prevents releasing with uncommitted work, it's nice to not have to worry about *anything* by performing release in a clean area - a release CI job or separate local checkout).
On Sun, Mar 24, 2013 at 3:24 PM, Andrei Pozolotin < [email protected]> wrote: > I do not mind - "children being part of the tag ". > > so what is the way to release a parent w/o its modules? > > -------- Original Message -------- > Subject: Re: Multi-project releases > From: Stephen Connolly <[email protected]> > To: Maven Developers List <[email protected]> > Date: Sun 24 Mar 2013 02:30:10 PM CDT > > That's still going to result in all the children being part of the tag > > though > > > > On Sunday, 24 March 2013, Jeff Jensen wrote: > > > >> -N > >> Same for other operations to not recurse into children/modules. > >> > >> > >> On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin < > >> [email protected] <javascript:;>> 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 <[email protected]> > >>> To: Maven Developers List <[email protected]>, Andrei Pozolotin > >>> <[email protected]> > >>> Cc: "Stephen Connolly" <[email protected]> > >>> 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 > >>>> <[email protected]>: > >>>> > >>>>> 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 <[email protected]> > >>>>> To: Maven Developers List <[email protected]> > >>>>> 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" > > > > > >
