I'm working on making the grizzly deployments actually work with maven
(currently we have an involved set of instructions due, in part, to java.net's
wonderous performance but that's a rant for another time). Given this pom:
https://grizzly.dev.java.net/svn/grizzly/trunk/code/modules/utils/pom.xml
and the command:
mvn -e -DdryRun=$DRYRUN -DautoVersionSubmodules=true
-DdevelopmentVersion=1.9.19-SNAPSHOT -DreleaseVersion=1.9.19-beta2
-Dtag=1_9_19_beta2 -DallowTimestampedSnapshots=true
-DupdateDependencies=false release:clean release:prepare
I get this error:
[INFO] Transforming 'grizzly-project'...
[INFO] Transforming 'grizzly-lzma'...
[INFO] Transforming 'grizzly-utils'...
[INFO] Updating grizzly-lzma to 1.9.19-beta2
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] The version could not be updated: ${grizzly-version}
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.BuildFailureException: The version could not be updated:
${grizzly-version}
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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:592)
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.MojoFailureException: The version could
not be updated: ${grizzly-version}
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:169)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
The problem, it seems, is that we use the property grizzly-version defined
in the root pom (https://grizzly.dev.java.net/svn/grizzly/trunk/code/pom.xml)
to specify the intermodule dependencies. Now, I've seen poms that don't
specify the module versions in the deps but when I try that, the pom fails
to validate. So I guess I have two questions:
1. Can we not use the property for the dependency version number like
that? Do we need to hard code the project version?
2. How can we eliminate that version entry from the dependency
altogether? That'd be the simplest way, i think, if it works that way.
