Maven 2.x Release Plugin

release:prepare should not require multimodule artifacts to be in the local repository

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0
  • Component/s: prepare
  • Labels:
    None
  • Number of attachments :
    0

Description

Currently, if you try to run release:prepare on a multimodule project after removing any of that build's artifacts from the local repository, it will fail. Investigate why release:prepare needs the multimodule artifacts installed in the local repository before it can succeed.

To reproduce, comment the following line in it2002/test.sh:

mvn clean install

NOTE: This may have to do with the version resolution code, which is used to resolve SNAPSHOT versions.

Issue Links

This issue is duplicated by:
MRELEASE-330 target release:prepare fails for multiproject if cross project dependencies exist Blocker Closed
MRELEASE-102 Preparation goals 'clean integration-test' not sufficient for plugin-projects Major Closed
MRELEASE-228 release:prepare should not require multimodule artifacts to be in the local repository Major Closed
This issue relates to:
MRELEASE-388 @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies Critical Closed
MRELEASE-326 Doens't resolve multiproject dependencies properly Major Closed
MRELEASE-62 Option not to run install phase during realease:prepare Major Closed
This issue is related to:
MRELEASE-240 release-pom.xml does not contain <dependencies> and <dependencyManagement> Major Closed
MNG-4331 Add new mojo annotation @requiresDependencyCollection to grab dependency tree without files Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Tran added a comment -

does it mean, after reach daily release where we have a new snaphot version, I must install a snapshot of my build artifact to my local repo? ( mvn install ) so that the next release:prepare would work.

Show
Dan Tran added a comment - does it mean, after reach daily release where we have a new snaphot version, I must install a snapshot of my build artifact to my local repo? ( mvn install ) so that the next release:prepare would work.
Hide
Permalink
John Casey added a comment -

appears that the project references aren't being resolved correctly. I'll have to attach a debugger and figure out why.

UPDATE: To duplicate this problem, you actually need to:

1. Remove all traces of org/apache/maven/it2002/* from your local repo
2. Comment out the line: 'mvn clean install' in it2002/test.sh
3. Run test.sh in it2002 dir.

Show
John Casey added a comment - appears that the project references aren't being resolved correctly. I'll have to attach a debugger and figure out why. UPDATE: To duplicate this problem, you actually need to: 1. Remove all traces of org/apache/maven/it2002/* from your local repo 2. Comment out the line: 'mvn clean install' in it2002/test.sh 3. Run test.sh in it2002 dir.
Hide
Permalink
Brett Porter added a comment -

"Project references" - I assume you mean project.getArtifact() ? This can only happen when the artifact is created (or a semblance of it) - ie at compile, package, install phases where it is target/classes, target/XXX.jar or the local repository versions respectively.

Show
Brett Porter added a comment - "Project references" - I assume you mean project.getArtifact() ? This can only happen when the artifact is created (or a semblance of it) - ie at compile, package, install phases where it is target/classes, target/XXX.jar or the local repository versions respectively.
Hide
Permalink
Dan Tran added a comment -

John, Do you have any progress on this JIRA? I have a scenario where I need to do a release:prepare without the availablity of the snapshots.
Let me know what I can do to help.

Show
Dan Tran added a comment - John, Do you have any progress on this JIRA? I have a scenario where I need to do a release:prepare without the availablity of the snapshots. Let me know what I can do to help.
Hide
Permalink
Barrie Treloar added a comment -

MRELEASE-182 (release:prepare preparationGoals should be "clean verify") may be related to this issue.

I disagree with the recommendation in MRELEASE-182 as I believe that "install" needs to happen as part of release:prepare.

The scenario is this:

  • module projects are executed with existing default goals (clean integration-test)
  • deployment module gets executed which has an assembly which attempts to collect all the previous module artifact's and place them into a distributable archive.

The deployment module will fail since none of the artifacts are available in the local repository.

According to http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html:
"package" < "integration-test" < "install" and hence the deployment module will cause failures in the release process.

My workaround is to manually run mvn install when the release process fails and then to restart the release.

Show
Barrie Treloar added a comment - MRELEASE-182 (release:prepare preparationGoals should be "clean verify") may be related to this issue. I disagree with the recommendation in MRELEASE-182 as I believe that "install" needs to happen as part of release:prepare. The scenario is this:
  • module projects are executed with existing default goals (clean integration-test)
  • deployment module gets executed which has an assembly which attempts to collect all the previous module artifact's and place them into a distributable archive.
The deployment module will fail since none of the artifacts are available in the local repository. According to http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html: "package" < "integration-test" < "install" and hence the deployment module will cause failures in the release process. My workaround is to manually run mvn install when the release process fails and then to restart the release.
Hide
Permalink
Emmanuel Venisse added a comment -

John, I think this problem is fixed in latest code. Can you verify?

Show
Emmanuel Venisse added a comment - John, I think this problem is fixed in latest code. Can you verify?
Hide
Permalink
Damien Lecan added a comment -

Snapshot of the plugin from rev 530675 doesn't need to have artifacts in the local repository.

Good job

Show
Damien Lecan added a comment - Snapshot of the plugin from rev 530675 doesn't need to have artifacts in the local repository. Good job
Hide
Permalink
Sundeep Sharma added a comment -

I am facing same issue with 2.0.6.

Show
Sundeep Sharma added a comment - I am facing same issue with 2.0.6.
Hide
Permalink
Kuno Baeriswyl added a comment -

I think I got the same problem with Maven 2.0.8

Show
Kuno Baeriswyl added a comment - I think I got the same problem with Maven 2.0.8
Hide
Permalink
Dan Tran added a comment -

Dont think it is fixed, my maven is 2.0.9 using release plugin that binds with the maven version.

Show
Dan Tran added a comment - Dont think it is fixed, my maven is 2.0.9 using release plugin that binds with the maven version.
Hide
Permalink
Dan Tran added a comment -

I made an attempt to do a test release:prepare of surefire ( ofcourse with network cutoff) and no local artifacts

mvn release:prepare -P -DpreparationGoals=clean"

It went fine ( fails at expected svn commit ).

So the problem is little more troubling, could be due to the way I setup up my company maven project which is much bigger then surefire.

Show
Dan Tran added a comment - I made an attempt to do a test release:prepare of surefire ( ofcourse with network cutoff) and no local artifacts mvn release:prepare -P -DpreparationGoals=clean" It went fine ( fails at expected svn commit ). So the problem is little more troubling, could be due to the way I setup up my company maven project which is much bigger then surefire.
Hide
Permalink
Olivier Lamy added a comment -

IMHO it's more a MNG issue.
If you run your project with clean verify, with a clean repo and no modules deployed as a SNAPSHOT, it will fail too.
SO use -DpreparationGoals="clean install"

Show
Olivier Lamy added a comment - IMHO it's more a MNG issue. If you run your project with clean verify, with a clean repo and no modules deployed as a SNAPSHOT, it will fail too. SO use -DpreparationGoals="clean install"
Hide
Permalink
Dan Tran added a comment -

setting preparationGoals="clean install" will work, but for a large project with daily release, the build time is double.

Show
Dan Tran added a comment - setting preparationGoals="clean install" will work, but for a large project with daily release, the build time is double.
Hide
Permalink
Olivier Lamy added a comment -

IMHO again it's more a MNG issue !

Show
Olivier Lamy added a comment - IMHO again it's more a MNG issue !
Hide
Permalink
Job de Noo added a comment -

have te same issue that it will not resolve reactor dependencies in maven 2.2

Show
Job de Noo added a comment - have te same issue that it will not resolve reactor dependencies in maven 2.2
Hide
Permalink
Youri De Bondt added a comment - - edited

-DpreparationGoals="clean install" doesn't work for me.
I have to perform a clean install first, then release:prepare (which will check if the modules are installed, and also runs clean install)

Show
Youri De Bondt added a comment - - edited -DpreparationGoals="clean install" doesn't work for me. I have to perform a clean install first, then release:prepare (which will check if the modules are installed, and also runs clean install)
Hide
Permalink
Brett Porter added a comment -

See the following thread for the planned resolution to this: http://mail-archives.apache.org/mod_mbox/maven-dev/201001.mbox/%3C4B56E5A7.9050806@udo.edu%3E

Show
Brett Porter added a comment - See the following thread for the planned resolution to this: http://mail-archives.apache.org/mod_mbox/maven-dev/201001.mbox/%3C4B56E5A7.9050806@udo.edu%3E

People

Vote (20)
Watch (19)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.