Maven 2.x Release Plugin

Properties releaseVersion and developmentVersion are not read correctly during release:prepare (eventually release:perform)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Cannot Reproduce
  • Affects Version/s: 2.0-beta-8
  • Fix Version/s: 2.0
  • Component/s: prepare
  • Labels:
    None
  • Environment:
    Maven version: 2.0.9
    Java version: 1.6.0_07
    OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
    scm=CVS
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

Calling
mvn --batch-mode release:prepare release:perform -Dtag=TEST_RELEASE-3_0_0 -DreleaseVersion=3.0.0 -DdevelopmentVersion=3.0.1-SNAPSHOT
doesn't produce the expected results:

  • -DdevelopmentVersion=3.0.1-SNAPSHOT
    • the value is not set correctly in the file pom.xml:
      • Expected: <version>3.0.1-SNAPSHOT</version>
      • But was: <version>2.0.5-SNAPSHOT</version>
  • -DreleaseVersion=3.0.0
    • the artifacts are not created correctly:
      • Expected artifact: ipi-multimodule-b-3.0.0.jar
      • But was: ipi-multimodule-b-2.0.4.jar
    • the value is not set correctly in the file pom.xml (comment in CVS: [maven-release-plugin] prepare release TEST_RELEASE-3_0_0):
      • Expected: <version>3.0.0</version>
      • But was: <version>2.0.4</version>
  • -Dtag=TEST_RELEASE-3_0_0
    • the value is set correctly in the file pom.xml
    • the tagging of the CVS module is also correct.

Issue Links

This issue relates to:
MRELEASE-387 command line versions don't seem to work on release:branch Major Closed
This issue is related to:
MRELEASE-128 SCM properties being replaced during release:perform Critical Reopened
MRELEASE-173 Allow command line specification of versions Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ringo De Smet added a comment - - edited

Patch-MRELEASE-389.txt contains a patch for this issue against the following file:

maven-release-manager/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java

This patch has been tested manually using a private version of maven-release-manager and maven-release-plugin.

Can this be taken along for maven-release-plugin 2.0-beta-9 release?

Ringo

Show
Ringo De Smet added a comment - - edited Patch-MRELEASE-389.txt contains a patch for this issue against the following file: maven-release-manager/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java This patch has been tested manually using a private version of maven-release-manager and maven-release-plugin. Can this be taken along for maven-release-plugin 2.0-beta-9 release? Ringo
Hide
Permalink
Paul Gier added a comment -

I wasn't able to reproduce this. Can you provide more information?
I ran a release:prepare in batch mode using -DdevelopmentVersion and releaseVersion and both were set correctly in the release.properties and in the poms.
Did you do a release:prepare before the release? Or did you have any other settings that might have interfered?

Show
Paul Gier added a comment - I wasn't able to reproduce this. Can you provide more information? I ran a release:prepare in batch mode using -DdevelopmentVersion and releaseVersion and both were set correctly in the release.properties and in the poms. Did you do a release:prepare before the release? Or did you have any other settings that might have interfered?
Hide
Permalink
Ringo De Smet added a comment - - edited

I did not use batch mode.

However, looking at the source, I do not understand where the command-line properties are pushed towards a ReleaseDescriptor object besides the method ReleaseUtils.copyPropertiesToReleaseDescriptor(Properties).

With Maven 2.0.9 and maven-release-plugin:2.0-beta-8, I have never been able to have the command-line properties to be pushed through. If I configured the properties in the configuration section of the plugin under build>plugins>plugin in the POM, it works as expected. Via that path, the properties are set through the Plexus container on another ReleaseDescriptor object populated in PrepareReleaseMojo.execute()

Should there be another piece of code that transforms command line arguments to properties accessible to the Plexus container?

Ringo

Show
Ringo De Smet added a comment - - edited I did not use batch mode. However, looking at the source, I do not understand where the command-line properties are pushed towards a ReleaseDescriptor object besides the method ReleaseUtils.copyPropertiesToReleaseDescriptor(Properties). With Maven 2.0.9 and maven-release-plugin:2.0-beta-8, I have never been able to have the command-line properties to be pushed through. If I configured the properties in the configuration section of the plugin under build>plugins>plugin in the POM, it works as expected. Via that path, the properties are set through the Plexus container on another ReleaseDescriptor object populated in PrepareReleaseMojo.execute() Should there be another piece of code that transforms command line arguments to properties accessible to the Plexus container? Ringo
Hide
Permalink
jcrouvi added a comment -

Test

Show
jcrouvi added a comment - Test
Hide
Permalink
jcrouvi added a comment -

I have just tested it again and it works (??). I can not reproduce the bug.

  • Before the tests I called:
    • mvn clean
    • mvn release:clean
  • The version of the original pom file before the test was:
    <version>4.0.2-SNAPSHOT</version>

The reason of the unexpected behiaviour is perhaps the patch and the modification I made to the maven-release-manager because of the bug
http://jira.codehaus.org/browse/MRELEASE-128?actionOrder=desc

I attached the protocol of my test: text file jcrouvi_20081204_test.log

Show
jcrouvi added a comment - I have just tested it again and it works (??). I can not reproduce the bug.
  • Before the tests I called:
    • mvn clean
    • mvn release:clean
  • The version of the original pom file before the test was: <version>4.0.2-SNAPSHOT</version>
The reason of the unexpected behiaviour is perhaps the patch and the modification I made to the maven-release-manager because of the bug http://jira.codehaus.org/browse/MRELEASE-128?actionOrder=desc I attached the protocol of my test: text file jcrouvi_20081204_test.log
Hide
Permalink
Paul Gier added a comment -

However, looking at the source, I do not understand where the command-line properties are pushed towards a ReleaseDescriptor object besides the method ReleaseUtils.copyPropertiesToReleaseDescriptor(Properties).

Ringo,
You should be able to set the version plugin parameters through the command line using those properties (releaseVersion and developmentVersion). The plugin parameters are configured to pick up the command line properties like this.

/** 
 * @parameter expression="${releaseVersion}"
 */
private String releaseVersion;

The copy properties part is only used to pick up properties that can't be set through the plugin parameters. For example the module specific versions in a multi module release.

But if it's not working for you with 2.0-beta-8 or the beta-9 snapshot then there must be something else going wrong. And if you can help me track it down, I can try to fix it.

Show
Paul Gier added a comment -
However, looking at the source, I do not understand where the command-line properties are pushed towards a ReleaseDescriptor object besides the method ReleaseUtils.copyPropertiesToReleaseDescriptor(Properties).
Ringo, You should be able to set the version plugin parameters through the command line using those properties (releaseVersion and developmentVersion). The plugin parameters are configured to pick up the command line properties like this. 
/** 
 * @parameter expression="${releaseVersion}"
 */
private String releaseVersion;
The copy properties part is only used to pick up properties that can't be set through the plugin parameters. For example the module specific versions in a multi module release. But if it's not working for you with 2.0-beta-8 or the beta-9 snapshot then there must be something else going wrong. And if you can help me track it down, I can try to fix it.
Hide
Permalink
Ringo De Smet added a comment -

I think I found the reason why it didn't work for me: the releaseVersion and developmentVersion properties only seem to be picked up from the command line properties if you use the batch-mode argument. Correct? If so, this wasn't completely clear from the documentation.

However, if I just run mvn release:prepare, the release plugin doesn't prompt me for the release and development versions. It just calculates the next version from the current goes on with preparing a release. Anyone knows what the cause could be?

Show
Ringo De Smet added a comment - I think I found the reason why it didn't work for me: the releaseVersion and developmentVersion properties only seem to be picked up from the command line properties if you use the batch-mode argument. Correct? If so, this wasn't completely clear from the documentation. However, if I just run mvn release:prepare, the release plugin doesn't prompt me for the release and development versions. It just calculates the next version from the current goes on with preparing a release. Anyone knows what the cause could be?
Hide
Permalink
Paul Gier added a comment -

I'm closing this issue as "Cannot Reproduce" since I was not able to reproduce the problem and it seems to have gone away for the original submitter (jcrouvi).

Show
Paul Gier added a comment - I'm closing this issue as "Cannot Reproduce" since I was not able to reproduce the problem and it seems to have gone away for the original submitter (jcrouvi).
Hide
Permalink
James Roper added a comment -

I had exactly the same problem, -Dtag was honoured, but -DreleaseVersion and -DdevelopmentVersion wasn't working. The problem was I was using an older maven release plugin version and didn't realise it. Upgrading to 2.0-beta-9 solved the problem.

Show
James Roper added a comment - I had exactly the same problem, -Dtag was honoured, but -DreleaseVersion and -DdevelopmentVersion wasn't working. The problem was I was using an older maven release plugin version and didn't realise it. Upgrading to 2.0-beta-9 solved the problem.

People

Vote (5)
Watch (10)

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.