Hi, I found the problem, i was also using the enforcer-plugin in a parent pom.xml. It was configured with goal 'enforce-once' which prevented a correct release:prepare. I've got things working now.
Another problem was with Archiva, which is a bit unstable when it comes to deploying 1 artifact multiple times in a short period. Some files are made read-only which cause an '507 Insufficient Storage' error. Restarting solves this problem, temporarily. Thanks for the tips and help, Maarten ----- Original Message ---- From: maarten roosendaal <[EMAIL PROTECTED]> To: Maven Users List <[email protected]> Sent: Tuesday, October 30, 2007 1:15:07 PM Subject: Re: maven-release-plugin best practice question I don't understand the first remark. It shouldn't matter what packaging it is (jar, war, ejb, sar) should it? I configured the release plugin just as posted but the result remains the same. Here is the log: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MainProject [INFO] Module-B [INFO] Module-A [INFO] Searching repository for plugin with prefix: 'release'. WAGON_VERSION: 1.0-beta-1 [INFO] ---------------------------------------------------------------------------- [INFO] Building MainProject [INFO] task-segment: [release:prepare] (aggregator-style) [INFO] ---------------------------------------------------------------------------- [INFO] [release:prepare] [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [INFO] Transforming 'MainProject'... [INFO] Updating Module-A to 0.0.1 [INFO] Ignoring artifact version update for expression: ${project.version} [INFO] Updating Module-B to 0.0.1 [INFO] Ignoring artifact version update for expression: ${project.version} [INFO] Checking out file: C:\ccviews\view\project\04.Implementation\pom.xml [INFO] Transforming 'Module-B Project'... [INFO] Checking out file: C:\ccviews\view\project\04.Implementation\Module-B\pom.xml [INFO] Transforming 'Module-A Project'... [INFO] Updating Module-B to 0.0.1 [INFO] Checking out file: C:\ccviews\view\project\04.Implementation\Module-A\pom.xml [INFO] Not generating release POMs [INFO] Executing goals 'clean install'... [INFO] Executing: mvn clean install --no-plugin-updates --batch-mode -P repo-proxy,repo-proxy [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MainProject [INFO] Module-B Project [INFO] Module-A Project WAGON_VERSION: 1.0-beta-1 [INFO] ---------------------------------------------------------------------------- [INFO] Building MainProject [INFO] task-segment: [clean, install] [INFO] ---------------------------------------------------------------------------- [INFO] [clean:clean] [INFO] Deleting directory C:\ccviews\view\project\04.Implementation\target [INFO] Deleting directory C:\ccviews\view\project\04.Implementation\target\classes [INFO] Deleting directory C:\ccviews\view\project\04.Implementation\target\test-classes [INFO] Deleting directory C:\ccviews\view\project\04.Implementation\target\site [INFO] [cobertura:clean {execution: default}] Downloading: http://archiva:8180/archiva/repository/internal//com/ibm/db2/db2java/1.0/db2java-1.0.pom Downloading: http://repo1.maven.org/maven2/com/ibm/db2/db2java/1.0/db2java-1.0.pom Downloading: http://archiva:8180/archiva/repository/internal//nl/module-b/0.0.1/module-b-0.0.1.jar Downloading: http://repo1.maven.org/maven2/nl/module-b/0.0.1/module-b-0.0.1.jar [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to resolve artifact. Missing: ---------- 1) nl:module-b:jar:0.0.1 Try downloading the file manually from the project website. Then, install it using the command: <omitted> Path to dependency: 1) nl:module-a:jar:0.0.1 2) nl:module-b:jar:0.0.1 ---------- 1 required artifact is missing. for artifact: nl:module-a:jar:0.0.1 from the specified remote repositories: ...... [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 12 seconds [INFO] Finished at: Tue Oct 30 12:37:27 CET 2007 [INFO] Final Memory: 13M/32M [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 42 seconds [INFO] Finished at: Tue Oct 30 12:37:29 CET 2007 [INFO] Final Memory: 7M/33M [INFO] ------------------------------------------------------------------------ So what you see is that maven will look for module-b in de archiva repo when it should not be looking for anything at that point. ----- Original Message ---- From: Nicole Lacoste <[EMAIL PROTECTED]> To: Maven Users List <[email protected]> Sent: Tuesday, October 30, 2007 12:16:33 PM Subject: Re: maven-release-plugin best practice question Um, not sure. Whats the packaging on module A? If its not a jar, you must make sure its installed, by as Graham said configuring the release plugin in the parent pom's build section as follows. <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.0-beta-6</version> <configuration> <preparationGoals>clean install</preparationGoals> </configuration> </plugin> BTW there is a ne version of the release plugin 2.0-beta-7 On 30/10/2007, maarten roosendaal <[EMAIL PROTECTED]> wrote: > > I did delete all the versions in the coordinates and dependencies of the > childpom's (except for the parent which is an explicit definition --> > 0.0.1-SNAPSHOT not ${project.version}) and added > dependencyManagement for all modules with ${project.version}. > > However performing a release:prepare still fails because when building the > root project it says that it can't find > a version of module A (0.0.1). I have both modules as part of the > module-tag in the root pom.xml and a normal install works fine. > > What parameters are you using when calling release:prepare? How did you > configure the plugin? > > ----- Original Message ---- > From: Nicole Lacoste <[EMAIL PROTECTED]> > To: Maven Users List <[email protected]> > Sent: Tuesday, October 30, 2007 9:39:14 AM > Subject: Re: maven-release-plugin best practice question > > > Hi, > > Don't put ANY versions in child poms EXCEPT for the parent version. If > module B depends on module A, declare the version of module A and B in > the > common parent pom dependency management section (your main project if I > understand right), with ${project.version}. There should only be one > <version>***</version> in any child pom and that is in parent section. > The > fact that you say that the version is not updated in the child, means > that > this is currently not the case, you currently are using a version > somewhere > in a child project, don't declare the child version, or his dependency > versions. In the dependency section, declare all artifacts without > version, > the versions are picked up from the dependency management of his > parent. > > Nicole > > > On 30/10/2007, maarten roosendaal <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Apparently this does not work for my project. It stil does not update > the > > versions in the dependencies. Using either $(pom.version} or $( > > project.version} with our without dependencyManagement still does not > > solve the issue. > > > > Just to be sure: > > project Main > > module A (dependent on module B) > > module B > > > > when doing a release:prepare (dryRun) you will see that in the > pom.xml.tagthe version of the dependency is update from > > 0.0.1-SNAPSHOT to 0.0.1 so that is good. But when i look in the > > pom.xml.next the dependency.version is still 0.0.1-SNAPSHOT in stead > of > > 0.0.2-SNAPSHOT. I believe this is a bug: MRELEASE-295. (i hope this > gets > > solved quickly, takes some manual labour to change all the versions); > > > > The addition of the configuration also does not work. My build starts > with > > the root pom.xml and at that point i get that it is missing version > 0.0.1of module B. So it doesn't even get to installing modules > atomically. > > > > I use: mvn --batch-mode release:prepare -DuseEditMode=true and i have > > added the plugin to the root pom.xml > > > > Any suggestions or ideas where to look or what to do? > > > > Thanks, > > Maarten > > > > > > > > ----- Original Message ---- > > From: Graham Leggett <[EMAIL PROTECTED]> > > To: Maven Users List <[email protected]> > > Cc: [email protected] > > Sent: Monday, October 29, 2007 4:29:25 PM > > Subject: Re: maven-release-plugin best practice question > > > > > > On Mon, October 29, 2007 5:18 pm, maarten roosendaal wrote: > > > > > I'm working with the maven-release-plugin and it works fine except > > for the > > > fact that my own <module>-<version>-SNAPSHOT dependencies in > various > > > pom.xml's do no get updated when performing a release:prepare. > > > > > > I thought i could use the dependencyManagement for this but when i > > use > > > this and do a release:prepare and start building, several modules > > will > > > look for dependencies with the release version instead of the old > > SNAPSHOT > > > version. > > > > > > What is the (best) way to avoid having to manually change all the > > > versionumbers in de dependencies in the pom.xml's (we have 12) > before > > > performing a release? > > > > If all 12 dependencies are typically released at the same time, then > > group > > them together as a multi-module build and release the multi-module > > build > > in one go. > > > > We set the version in the root pom of our multi-module build, and in > > all > > submodules, the version is inherited and accessed using > ${pom.version}. > > > > When the release:perform is run from the root of the multi-module > > build, > > all the version numbers are handled automatically. > > > > One thing that the release plugin likes to do when testing a > > multimodule > > build is to miss out the install phase, which can cause potential > > confusion as each of your submodules isn't installed and used by the > > next > > submodule. To work around this problem, add this to your root pom: > > > > <plugin> > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-release-plugin</artifactId> > > <version>2.0-beta-6</version> > > <configuration> > > <preparationGoals>clean install</preparationGoals> > > </configuration> > > </plugin> > > > > Regards, > > Graham > > -- > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
