Another means of doing this, is to always build module D as you put it.
But, assuming the distribution is just an application of the assembly
plugin (or it's derivatives in concept), just tie the execution of the
plugin(s) to the DEPLOY phase.
That's exactly how I achieved an upload on my package bundle into IBM RAM.
-Chris
On Thu, May 17, 2012 at 2:37 PM, Stephane Nicoll
<stephane.nic...@gmail.com>wrote:
> I tried that and it did not make any difference (with mvn 3.0.4). The
> project is BTM on codehaus if someone wants to try it out.
>
> Thanks,
> S.
>
> On Wed, May 16, 2012 at 7:43 PM, Robert Scholte <apa...@sourcegrounds.com
> >wrote:
>
> > Could you first update to version 2.3 and see if that makes any
> difference?
> >
> > -Robert
> >
> > Op Wed, 16 May 2012 19:21:29 +0200 schreef Stephane Nicoll <
> > stephane.nic...@gmail.com>:
> >
> > I am not sure, here is the partial log of the dryRun
> >>
> >> snicoll@cobra:~/Projects/btm$ mvn -DdryRun=true release:prepare
> >> [INFO] Scanning for projects...
> >> [INFO]
> >> ------------------------------**------------------------------**
> >> ------------
> >> [INFO] Reactor Build Order:
> >> [INFO]
> >> [INFO] Bitronix Transaction Manager
> >> [INFO] Bitronix Transaction Manager :: Core
> >> [INFO] Bitronix Transaction Manager :: Jetty 6 lifecycle
> >> [INFO] Bitronix Transaction Manager :: Jetty 7 lifecycle
> >> [INFO] Bitronix Transaction Manager :: Tomcat 5.5+ lifecycle
> >> [INFO]
> >>
> >> [INFO]
> >> ------------------------------**------------------------------**
> >> ------------
> >> [INFO] Building Bitronix Transaction Manager 2.1.3-SNAPSHOT
> >> [INFO]
> >> ------------------------------**------------------------------**
> >> ------------
> >> [INFO]
> >> [INFO] --- maven-release-plugin:2.1:**prepare (default-cli) @ btm-parent
> >> ---
> >> [INFO] Verifying that there are no local modifications...
> >> [INFO] ignoring changes on: pom.xml.next, release.properties,
> >> pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
> >> [INFO] Executing: /bin/sh -c cd /Users/snicoll/Projects/btm && git
> status
> >> [INFO] Working directory: /Users/snicoll/Projects/btm
> >> [INFO] Checking dependencies and plugins for snapshots ...
> >> What is the release version for "Bitronix Transaction Manager"?
> >> (org.codehaus.btm:btm-parent) 2.1.3: :
> >> What is SCM release tag or label for "Bitronix Transaction Manager"?
> >> (org.codehaus.btm:btm-parent) btm-parent-2.1.3: :
> >> What is the new development version for "Bitronix Transaction Manager"?
> >> (org.codehaus.btm:btm-parent) 2.1.4-SNAPSHOT: :
> >> [INFO] Transforming 'Bitronix Transaction Manager'...
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Updating btm-tomcat55-lifecycle to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Updating btm-jetty6-lifecycle to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Updating btm-jetty7-lifecycle to 2.1.3
> >> [INFO] Ignoring artifact version update for expression:
> ${project.version}
> >> [INFO] Transforming 'Bitronix Transaction Manager :: Core'...
> >> [INFO] Transforming 'Bitronix Transaction Manager :: Jetty 6
> lifecycle'...
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Transforming 'Bitronix Transaction Manager :: Jetty 7
> lifecycle'...
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Transforming 'Bitronix Transaction Manager :: Tomcat 5.5+
> >> lifecycle'...
> >> [INFO] Updating btm to 2.1.3
> >> [INFO] Not generating release POMs
> >> [INFO] Executing preparation goals - since this is simulation mode it is
> >> running against the original project, not the rewritten ones
> >> [INFO] Executing goals 'clean verify'...
> >> [INFO] Executing: /bin/sh -c cd /Users/snicoll/Projects/btm &&
> >> /usr/share/maven/bin/mvn clean verify --no-plugin-updates
> >> -Pcodehaus-release,dist -P local
> >> [WARNING] Command line option -npu is deprecated and will be removed
> in
> >> future Maven versions.
> >> [INFO] Scanning for projects...
> >> [INFO]
> >> ------------------------------**------------------------------**
> >> ------------
> >> [INFO] Reactor Build Order:
> >> [INFO]
> >> [INFO] Bitronix Transaction Manager
> >> [INFO] Bitronix Transaction Manager :: Core
> >> [INFO] Bitronix Transaction Manager :: Jetty 6 lifecycle
> >> [INFO] Bitronix Transaction Manager :: Jetty 7 lifecycle
> >> [INFO] Bitronix Transaction Manager :: Tomcat 5.5+ lifecycle
> >> [INFO] Bitronix Transaction Manager :: Distribution
> >>
> >> So the right projects are built by the forked process, good. But the
> main
> >> process is going to interpolate the poms (and in that case it's *not*
> >> there
> >> so its pom won't be changed).
> >>
> >> Thanks,
> >> S.
> >>
> >> On Wed, May 16, 2012 at 7:14 PM, Robert Scholte <
> apa...@sourcegrounds.com
> >> >**wrote:
> >>
> >> Looks like https://jira.codehaus.org/****browse/MRELEASE-571<
> https://jira.codehaus.org/**browse/MRELEASE-571>
> >>> <https://**jira.codehaus.org/browse/**MRELEASE-571<
> https://jira.codehaus.org/browse/MRELEASE-571>
> >>> >
> >>>
> >>> I have an idea how to fix this for Maven3 and if that works it'll be
> part
> >>> of 2.4
> >>>
> >>> -Robert
> >>>
> >>> Op Wed, 16 May 2012 19:05:14 +0200 schreef Stephane Nicoll <
> >>> stephane.nic...@gmail.com>:
> >>>
> >>>
> >>> Hi,
> >>>
> >>>>
> >>>> Is it me or it is not possible to add extra modules with the release
> >>>> plugin
> >>>> ?
> >>>>
> >>>> My use case is simple, I have a multi-modules project[1] that builds 3
> >>>> modules by default (A,B,C) and a "dist" profile adds an extra fourth
> >>>> project (D). When I release this project, I want to build A,B,C,D at
> >>>> both
> >>>> stage of course (because if the perform fail, I don't want it to
> commit
> >>>> the
> >>>> tag.
> >>>>
> >>>> So I used <arguments>-Pdist</arguments>
> >>>>
> >>>> I can see that the 4 projects are being build but the pom of D is not
> >>>> updated (version, etc). As a result the prepare work, the release
> works
> >>>> but
> >>>> it's trying to deploy a SNAPSHOT on release (which does not cause any
> >>>> issue
> >>>> btw). So I end up with build success except my D module is not in the
> >>>> staging repo.
> >>>>
> >>>> That's pretty bad. If I run the prepare and the perform with -Pdist
> (mvn
> >>>> release:prepare -Pdist) it works but the whole purpose of giving the
> >>>> feature to enable extra profile is that you don't need to worry about
> >>>> that.
> >>>>
> >>>> What am I missing?
> >>>>
> >>>> Thanks,
> >>>> S.
> >>>>
> >>>> [1]
> >>>> http://git.codehaus.org/****gitweb.cgi?p=btm-git.git;a=**<
> http://git.codehaus.org/**gitweb.cgi?p=btm-git.git;a=**>
> >>>> blob_plain;f=pom.xml;hb=****5f34fc2aee63b32b26781aea599abf**
> >>>> **5f6c73e101<http://git.**codehaus.org/gitweb.cgi?p=btm-**
> >>>> git.git;a=blob_plain;f=pom.**xml;hb=**5f34fc2aee63b32b26781aea599abf**
> >>>> 5f6c73e101<
> http://git.codehaus.org/gitweb.cgi?p=btm-git.git;a=blob_plain;f=pom.xml;hb=5f34fc2aee63b32b26781aea599abf5f6c73e101
> >
> >>>> >
> >>>>
> >>>>
>
