Maven 2.x Release Plugin

release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 2.0-beta-9
  • Fix Version/s: None
  • Component/s: prepare
  • Labels:
    None
  • Environment:
    Win Xp Pro 64bit Java 1.6
  • Number of attachments :
    1

Description

When I try to run release:prepare in batch mode, I get the error below (can't parse version string) even though I supply the version number by argument. If I do the same thing with the same versions in interactive mode, it works fine.

Here is the output:

------------------------------------------------------------------------

C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare release:perform
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
[INFO] task-segment: [release:prepare, release:perform] (aggregator-style)
[INFO] ------------------------------------------------------------------------
Downloading: http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
Downloading: http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in repository libs-releases-local (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
Downloading: http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in repository central (http://repo1.maven.org/maven2)
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
[INFO] Working directory: C:\workspaces\head\MyClient
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error parsing version, cannot determine next version: Unable to parse the version string: "MYB_200909-SNAPSHOT"

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing version, cannot determine next version: Unable to parse the version string: "MYB_200909-SNAPSHOT"
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error parsing version, cannot determine next version: Unable to parse the version string: "MYB_200909-SNAPSHOT"
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:186)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
... 17 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Error parsing version, cannot determine next version: Unable to parse the version string: "MYB_200909-SNAPSHOT"
at org.apache.maven.shared.release.phase.MapVersionsPhase.getNextVersion(MapVersionsPhase.java:227)
at org.apache.maven.shared.release.phase.MapVersionsPhase.execute(MapVersionsPhase.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:196)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:133)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:96)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:182)
... 19 more
Caused by: org.apache.maven.shared.release.versions.VersionParseException: Unable to parse the version string: "MYB_200909-SNAPSHOT"
at org.apache.maven.shared.release.versions.DefaultVersionInfo.<init>(DefaultVersionInfo.java:171)
at org.apache.maven.shared.release.phase.MapVersionsPhase.getNextVersion(MapVersionsPhase.java:177)
... 24 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Wed Jan 06 16:10:47 EST 2010
[INFO] Final Memory: 9M/18M
[INFO] ------------------------------------------------------------------------

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Cloutier added a comment -

Looking at the source code of: "org.apache.maven.shared.release.versions.DefaultVersionInfo.<init>(DefaultVersionInfo.java:157)" I understand why it's failing (It only accepts current versions to be numeric or alpha, not both ?!?!), I don't understand why I can get it to work in interactive mode.

Also, the standard and alternate regex's for the project versions seem overly stiff.

Plz help. We were asked to use the cvs branch names as version numbers and we don't control the branch names (they are made by another group.)

Thanks

Show
David Cloutier added a comment - Looking at the source code of: "org.apache.maven.shared.release.versions.DefaultVersionInfo.<init>(DefaultVersionInfo.java:157)" I understand why it's failing (It only accepts current versions to be numeric or alpha, not both ?!?!), I don't understand why I can get it to work in interactive mode. Also, the standard and alternate regex's for the project versions seem overly stiff. Plz help. We were asked to use the cvs branch names as version numbers and we don't control the branch names (they are made by another group.) Thanks
Hide
Permalink
David Cloutier added a comment -

Here is a svn patch of what I needed to change to get my version pattern to be accepted. (DefaultVersionInfo.java in maven-release-manager)

I also had to "break" a few jUnits not included in this patach as I just deleted them in my local workspace.

Show
David Cloutier added a comment - Here is a svn patch of what I needed to change to get my version pattern to be accepted. (DefaultVersionInfo.java in maven-release-manager) I also had to "break" a few jUnits not included in this patach as I just deleted them in my local workspace.
Hide
Permalink
Matthew Corby-Eaglen added a comment -

I have the same issue. +1 fix it please.

Show
Matthew Corby-Eaglen added a comment - I have the same issue. +1 fix it please.
Hide
Permalink
Chris DeLashmutt added a comment -

Still a problem on Maven 3.0

Show
Chris DeLashmutt added a comment - Still a problem on Maven 3.0
Hide
Permalink
Ion Iovu added a comment -

also, in interactive mode, if spaces are inserted before an otherwise valid value (e.g. 3.1.0125), the following warning is displayed:
[WARNING] Error parsing version, cannot determine next version: Unable to parse the version string: " 3.1.0125"
also, the result is having in the tag's pom.xml
<version> 3.1.0125</version>
that is, two spaces.
Could trimming be considered?

Show
Ion Iovu added a comment - also, in interactive mode, if spaces are inserted before an otherwise valid value (e.g. 3.1.0125), the following warning is displayed: [WARNING] Error parsing version, cannot determine next version: Unable to parse the version string: " 3.1.0125" also, the result is having in the tag's pom.xml <version> 3.1.0125</version> that is, two spaces. Could trimming be considered?
Hide
Permalink
Bram added a comment -

Still present in 3.0 indeed. It fails on even the simplest versions, like Test-1 or Test-1.0

What I don't get it why on earth the plugin tries to parse the version string in the first place. I provided all required parameters (scm tag, release version, next version) as command line options.

Show
Bram added a comment - Still present in 3.0 indeed. It fails on even the simplest versions, like Test-1 or Test-1.0 What I don't get it why on earth the plugin tries to parse the version string in the first place. I provided all required parameters (scm tag, release version, next version) as command line options.
Hide
Permalink
Bram added a comment -

It looks like MapVersionsPhase.getNextVersion() is trying to be a bit too smart. It tries to parse the current version number when it really shouldn't. It should first check ReleaseDescriptor's releaseVersions map to see if it contains a value for the next release. If not, then it should execute the current flow.

I don't have time to create a patch for this now, and I don't know the release plugin well enough to say if my above explanation is completely accurate, but at first glance, I think it's close enough.

Show
Bram added a comment - It looks like MapVersionsPhase.getNextVersion() is trying to be a bit too smart. It tries to parse the current version number when it really shouldn't. It should first check ReleaseDescriptor's releaseVersions map to see if it contains a value for the next release. If not, then it should execute the current flow. I don't have time to create a patch for this now, and I don't know the release plugin well enough to say if my above explanation is completely accurate, but at first glance, I think it's close enough.
Hide
Permalink
David Sklar added a comment - - edited

FWIW, I am using the following ruby/expect script to run release:prepare to work around this problem:

#!/usr/bin/env ruby

require 'pty'
require 'expect'
require 'rexml/document'


base_dir = "/path/to/my/project"
pom_file = base_dir + "/pom.xml"

raise "Can't read #{pom_file}" unless File.readable? pom_file

pom = REXML::Document.new(File.new(pom_file))

raise "Can't find project version in #{pom_file}" unless pom.elements['project/version']

version = pom.elements['project/version'].text

release_version = version.gsub(/-SNAPSHOT/,'')
scm_tag = "project-" + release_version

# Write a make_new_development_version() function appropriate to 
# whatever format you're using for your version strings
development_version = make_new_development_version(release_version)

# $expect_verbose = true
PTY.spawn("mvn -Dresume=false release:prepare") do |reader, writer, pid|
  reader.expect(/What is the release version for.+: :/)
  writer.puts(release_version)
  reader.expect(/What is SCM release tag or label for.+: :/)
  writer.puts(scm_tag)
  reader.expect(/What is the new development version for.+: :/)
  writer.puts(development_version)
  
  reader.each { |line| print line }
end
Show
David Sklar added a comment - - edited FWIW, I am using the following ruby/expect script to run release:prepare to work around this problem: 
#!/usr/bin/env ruby

require 'pty'
require 'expect'
require 'rexml/document'


base_dir = "/path/to/my/project"
pom_file = base_dir + "/pom.xml"

raise "Can't read #{pom_file}" unless File.readable? pom_file

pom = REXML::Document.new(File.new(pom_file))

raise "Can't find project version in #{pom_file}" unless pom.elements['project/version']

version = pom.elements['project/version'].text

release_version = version.gsub(/-SNAPSHOT/,'')
scm_tag = "project-" + release_version

# Write a make_new_development_version() function appropriate to 
# whatever format you're using for your version strings
development_version = make_new_development_version(release_version)

# $expect_verbose = true
PTY.spawn("mvn -Dresume=false release:prepare") do |reader, writer, pid|
  reader.expect(/What is the release version for.+: :/)
  writer.puts(release_version)
  reader.expect(/What is SCM release tag or label for.+: :/)
  writer.puts(scm_tag)
  reader.expect(/What is the new development version for.+: :/)
  writer.puts(development_version)
  
  reader.each { |line| print line }
end
Hide
Permalink
Miguel Almeida added a comment -

Same issue here in terminal.
Running:

mvn release:prepare -Dresume=false -DpreparationGoals="clean install" -DdevelopmentVersion="1.0.1-SNAPSHOT" -DreleaseVersion="EFAC-1.0.0"

It still says it cannot parse development and release versions-

Show
Miguel Almeida added a comment - Same issue here in terminal. Running: mvn release:prepare -Dresume=false -DpreparationGoals="clean install" -DdevelopmentVersion="1.0.1-SNAPSHOT" -DreleaseVersion="EFAC-1.0.0" It still says it cannot parse development and release versions-
Hide
Permalink
Anthony BOUQUET added a comment - - edited

Same issue here, I understand that versions number should be logical but the plugin should be less restrictif on the first argument before the first dot.

Versions like XXX.0.1 (with XXX alphanumerical) should be parsed correctly

Edit : Maven version 2.2.1, maven-release-plugin 2.2.1

Show
Anthony BOUQUET added a comment - - edited Same issue here, I understand that versions number should be logical but the plugin should be less restrictif on the first argument before the first dot. Versions like XXX.0.1 (with XXX alphanumerical) should be parsed correctly Edit : Maven version 2.2.1, maven-release-plugin 2.2.1

People

Vote (14)
Watch (13)

Dates

  • Created:
    Updated:
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.