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

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-330 target release:prepare fails for multiproject if cross project dependencies exist

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-102 Preparation goals 'clean integration-test' not sufficient for plugin-projects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-228 release:prepare should not require multimodule artifacts to be in the local repository

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-240 release-pom.xml does not contain <dependencies> and <dependencyManagement>

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

New Feature - A new feature of the product, which has yet to be developed. MNG-4331 Add new mojo annotation @requiresDependencyCollection to grab dependency tree without files

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-388 @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-62 Option not to run install phase during realease:prepare

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-326 Doens't resolve multiproject dependencies properly

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
John Casey made changes -
Field Original Value New Value
Fix Version/s 2.0.1 [ 12000 ]
Fix Version/s 2.0.2 [ 12107 ]
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.
John Casey made changes -
Assignee John Casey [ jdcasey ]
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.
Jason van Zyl made changes -
Project Maven 2 [ 10500 ] Maven 2.x Release Plugin [ 11144 ]
Component/s maven-release-plugin [ 11800 ]
Affects Version/s 2.0.1 [ 12000 ]
Fix Version/s 2.0.3 [ 12107 ]
Key MNG-1766 MRELEASE-3
Workflow Maven [ 43284 ] jira [ 44271 ]
Jason van Zyl made changes -
Workflow jira [ 44271 ] Maven [ 44943 ]
Jason van Zyl made changes -
Fix Version/s 2.0-beta-5 [ 12269 ]
John Casey made changes -
Assignee John Casey [ jdcasey ]
Brett Porter made changes -
Workflow Maven [ 44943 ] Maven New [ 52263 ]
Brett Porter made changes -
Fix Version/s 2.0 [ 12571 ]
Fix Version/s 2.0-beta-4 [ 12367 ]
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.
Jason van Zyl made changes -
Fix Version/s 2.0 [ 12571 ]
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
Emmanuel Venisse made changes -
Assignee Emmanuel Venisse [ evenisse ]
Resolution Fixed [ 1 ]
Fix Version/s 2.0-beta-5 [ 13024 ]
Status Open [ 1 ] Closed [ 6 ]
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.
Kuno Baeriswyl made changes -
Link This issue relates to MRELEASE-326 [ MRELEASE-326 ]
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.
Dan Tran made changes -
Resolution Fixed [ 1 ]
Status Closed [ 6 ] Reopened [ 4 ]
Olivier Lamy made changes -
Fix Version/s 2.0-beta-5 [ 13024 ]
Dan Tran made changes -
Fix Version/s 2.0-beta-8 [ 13812 ]
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.
Olivier Lamy made changes -
Link This issue is duplicated by MRELEASE-330 [ MRELEASE-330 ]
Olivier Lamy made changes -
Link This issue is duplicated by MRELEASE-102 [ MRELEASE-102 ]
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"
Olivier Lamy made changes -
Fix Version/s 2.0-beta-8 [ 13812 ]
Fix Version/s 2.0-beta-9 [ 14682 ]
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.
Dan Tran made changes -
Link This issue relates to MRELEASE-62 [ MRELEASE-62 ]
Arnaud Heritier made changes -
Link This issue relates to MRELEASE-388 [ MRELEASE-388 ]
Arnaud Heritier made changes -
Component/s prepare [ 13615 ]
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 !
Olivier Lamy made changes -
Assignee Emmanuel Venisse [ evenisse ]
Fix Version/s Future [ 15102 ]
Fix Version/s 2.0-beta-9 [ 14682 ]
Paul Gier made changes -
Link This issue is duplicated by MRELEASE-228 [ MRELEASE-228 ]
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)
Benjamin Bentmann made changes -
Link This issue is related to MNG-4331 [ MNG-4331 ]
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
Brett Porter made changes -
Fix Version/s Future [ 15102 ]
Fix Version/s 2.0 [ 15113 ]
Brett Porter made changes -
Link This issue is related to MRELEASE-240 [ MRELEASE-240 ]
Brett Porter made changes -
Assignee Brett Porter [ brettporter ]
Status Reopened [ 4 ] Closed [ 6 ]
Resolution Fixed [ 1 ]

People

  • Assignee:
    Brett Porter
    Reporter:
    John Casey
Vote (20)
Watch (19)

Dates

  • Created:
    Updated:
    Resolved: