Details
Description
After upgrading to 2.0.8 I find that the release plugin throws NPE if any dependency uses version range.
I have one dependency with version range <version>[1.0,2.0)</version> the rest are test scope with fixed version.
Here is the crash stack trace:
java.lang.NullPointerException: version was null for com.xrite:xrite-colorlib-api
[13:42:05]: at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
[13:42:05]: at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557)
[13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
[13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138)
[13:42:05]: at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106)
[13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
[13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131)
[13:42:05]: at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94)
[13:42:05]: at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127)
[13:42:05]: at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
[13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
[13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
[13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
[13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
[13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228)
[13:42:05]: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
[13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
[13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
[13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
[13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[13:42:05]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597)
[13:42:05]: at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[13:42:05]: at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
It seems the reason version is null is that the call to selectVersionFromNewRangeIfAvailable() assumes that versionRange.getRecommendedVersion() will always return non-null, else it sets the version to null! However during the release:prepare phase this is not true, see the output:
[13:42:04]: [INFO] [release:prepare]
[13:42:04]: [INFO] Verifying that there are no local modifications...
[13:42:04]: [INFO] Executing: svn --non-interactive status
[13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843
[13:42:05]: [INFO] Checking dependencies and plugins for snapshots ...
[13:42:05]: TEST!!! version=null
[13:42:05]: TEST!!! versionRange=[1.0,2.0)
[13:42:05]: TEST!!! getRecommendedVersion=null
TEST!!! Lines are my test code so I could see what is going on here.
-
Hide
- MNG-3351_dependency_poms.zip
- 22/Jan/08 7:17 PM
- 17 kB
- David Hoffer
-
- MNG-3351_dependency_poms/cxf1/pom.xml 7 kB
- MNG-3351_dependency_poms/.../pom.xml 14 kB
- MNG-3351_dependency_poms/.../pom.xml 0.9 kB
- MNG-3351_dependency_poms/pom.xml 21 kB
- MNG-3351_dependency_poms/readme.txt 0.2 kB
- MNG-3351_dependency_poms/settings.xml 10 kB
- MNG-3351_dependency_poms/.../pom.xml 12 kB
- MNG-3351_dependency_poms/.../pom.xml 1 kB
- MNG-3351_dependency_poms/.../pom.xml 0.5 kB
- MNG-3351_dependency_poms/.../pom.xml 13 kB
-
Hide
- MNG-3351.zip
- 22/Jan/08 1:54 PM
- 7 kB
- David Hoffer
-
- MNG-3351/pom.xml 21 kB
- MNG-3351/readme.txt 0.1 kB
- MNG-3351/settings.xml 10 kB
-
- MNG-3351-unittest.patch
- 29/Jan/08 7:15 AM
- 13 kB
- Mark Hobson
-
Hide
- simple-testcase.zip
- 23/Jan/08 6:22 AM
- 2 kB
- Mark Hobson
-
- a/pom.xml 1 kB
- b/pom-snapshot.xml 0.7 kB
- b/pom.xml 0.7 kB
-
- simple-test-case-console-log.txt
- 23/Jan/08 9:08 AM
- 5 kB
- David Hoffer
Issue Links
- depends upon
-
MNG-3092
Version ranges with non-snapshot bounds can contain snapshot versions
-
- is duplicated by
-
MRELEASE-414
NullPointerException at DefaultVersionInfo.java line 122
-
-
MRELEASE-574
NullPointerException in resolving ranges for test artifacts
-
-
MRELEASE-519
release plugin fails on version ranges
-
- is related to
-
MRELEASE-510
release:prepare resolves dependency ranges [1.0,) as SNAPSHOT
-
- relates to
-
MRELEASE-620
NPE on a range dependency
-
Activity
can you attach a simple pom that reproduces this crash? Putting it in the format of an IT would be awesome: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test
This fix appears to require a new release of Maven because the crash is in core code.
Perhaps I was a bit hasty when I said this effects 2.0-beta-7 as well. On the exact same project I released it today with 2.0.8 & 2.0-beta-7, when I went back and used 2.0-beta-6 I got this same error again.
Now if I go to a slightly more complicated build (just has more dependencies typically using version ranges) using 2.0.8 & 2.0-beta-7 I get a different problem. When doing the release:prepare it says:
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve th
em now? (yes/no) no: :
I have no idea what to select here. This is new, I have never seen this message before. However I have NO snapshot dependencies so why do I get this, it makes no sense to me. (Because releases can't have snapshots we always make sure we have none.)
If I select no it fails due to a false message that says it can't release project due to non released dependencies: com.xrite:xrite-commons:jar;[1.84,2.0):compile
Again, this is not a snapshot...am I getting tripped up by the maven bug MNG-3092 where it will accept snapshots if they exist in this range?
If I select yes then I get the following error:
[INFO] [release:prepare]
[INFO] Resuming release from phase 'check-dependency-snapshots'
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve th
em now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Depe
ndencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Resolve Project Dependency Snapshots.: [INFO] ----------------------------------
--------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1140)
at java.util.regex.Matcher.reset(Matcher.java:291)
at java.util.regex.Matcher.<init>(Matcher.java:211)
at java.util.regex.Pattern.matcher(Pattern.java:888)
at org.apache.maven.shared.release.versions.DefaultVersionInfo.<init>(De
faultVersionInfo.java:122)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.p
rocessSnapshot(CheckDependencySnapshotsPhase.java:392)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.r
esolveSnapshots(CheckDependencySnapshotsPhase.java:345)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.c
heckProject(CheckDependencySnapshotsPhase.java:227)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.e
xecute(CheckDependencySnapshotsPhase.java:106)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:194)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:131)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:94)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRe
leaseMojo.java:136)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:447)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:493)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:463)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:224)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.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)
So in summary 2.0.8 with 2.0-beta-7 works in one case and not in another. I'm not clear what test case to attach to this issue as I do not understand what is going on with 2.0-beta-7 & 2.0.8.
Brian, yes I can do that, the attached zip has my pom.xml and settings.xml file. Let me know if you need more information regarding dependencies or anything else.
Not knowing exactly what you need, this zip also contains the pom of each dependency (non-test scope, inhouse only). If I can help by simplifying this somehow, just let me know.
See simple-testcase.zip to easily reproduce:
1) b: mvn install
2) b: mvn -f pom-snapshot.xml install
3) a: mvn release:prepare
4) Type 'yes', press enter
5) Press enter
I'm not sure if this is a duplicate of MNG-3372, it just looks like the new snapshot resolving code doesn't cater for ranges. I'll have a look at fixing it now.
Mark, I was able to verify that your test case does indeed have re-create this bug. I have attached my console log running the steps you indicated. (http://jira.codehaus.org is very slow right now I can't get to MNG-3372 to take a look, I will try again later).
This is a problem with the release manager not coping with version ranges when prompting to resolve snapshots. See MNG-3351-unittest.patch to reproduce the problem.
To fix this we need to decide what the expected behaviour should be, which really depends on the outcome of MNG-3092.
For example, the unit test tries to release a project with a dependency version of [1.0,1.1) when versions 1.0-SNAPSHOT, 1.0 and 1.1-SNAPSHOT are available. If MNG-3092 is not applied, then the range contains 1.1-SNAPSHOT and the user is prompted to set the dependency to the release version. Now do we replace the range with 1.1 for releasing and then reinstate the range for further development? If so, we lose the range information in the released pom (which is the purpose of release-pom.xml) and how do we then increment the range to the next development version?
If MNG-3092 is applied, then the range resolves to 1.0, the user is not prompted and release poms will provide the resolved version. In this scenario we would have to extend the prompting code to cater for ranges with snapshot boundaries, for example [1.0,1.1-SNAPSHOT]. Here we would derive the release version to be [1.0,1.1] and proceed with the release.
Personally I'm in favour of the latter scenario.
Mark,
Yes, I prefer the latter secenario as well. It seems this is dependent on MNG-3092, how do we proceed to get resolution? What is the normal maven proceedure to do this?
If I can assist in any way, let me know.
-Dave
David, by carrying on the lengthy discussion on maven-dev I believe..
Is there an update on this issue? I just got hit with this bug using Maven 2.2.1 and Release plugin version 2.0. Grrr.
related to other issue, need to check if patch is still relevant
I applied the test case from Mark, with some modifications to not corrupt his other later test.
I fixed this by getting ranges to use the version they were resolved to for the project. This doesn't solve a more general problem about ranges, and particularly snapshots in ranges as discussed here - will defer that to the more specific issues.
Arik, I meant the reference to the MNG-3092 issue which is still being debated.
I managed to get this again on maven 2.1.0 with release plugin 2.1. Works fine on maven 3 however I would recommend upgrading to m3.
I'm getting this in 2.1 using an exact version number, e.g., [1.2.5]. 2.0-beta-9 works fine. Should I create a new bug or is there a way to re-open this? Migrating to Maven 3 is not an option for us at this time.
java.lang.NullPointerException: version was null for ad.3rdparty:boost
at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:273)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:136)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:98)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
...
It does not look like fixed here neither:
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty</artifactId>
<version>[6,7)</version>
</dependency>
mvn org.apache.maven.plugins:maven-release-plugin:2.1:prepare -DdryRun=true
[...]
java.lang.NullPointerException: version was null for org.mortbay.jetty:jetty
at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:273)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:136)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:98)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.simulate(CheckDependencySnapshotsPhase.java:290)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
[...]
Yeah. Not working for me in Maven 2.2.1 either. Exact same stack trace as the one from Michal Politowski
I'm still getting an NPE with Maven 2.2.1 and Release Plugin 2.1.
Relavent POM snip:
<dependencies>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>[1.2,)</version>
</dependency>
...
</dependencies>
Output:
mvn org.apache.maven.plugins:maven-release-plugin:2.1:prepare -DreleaseVersion=1.0.1-y2pilot -DdevelopmentVersion=1.0.2-y2pilot-SNAPSHOT -Dtag=1.0.1-y2pilot -DdryRun=true
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] common-services
[INFO] dcs-id-api
[INFO] dcs-id-impl
[INFO] dcs-notify-api
[INFO] dcs-notify-impl
[INFO] Common DCS utilities
[INFO] dcs-id-impl-hibernate
[INFO] ------------------------------------------------------------------------
[INFO] Building common-services
[INFO] task-segment: [org.apache.maven.plugins:maven-release-plugin:2.1:prepare] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [release:prepare
]
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties, pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: /bin/sh -c cd /Users/esm/dc-svn/common-services/branches/y2pilot && svn --non-interactive status
[INFO] Working directory: /Users/esm/dc-svn/common-services/branches/y2pilot
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.
: Do you want to resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Dependency 'org.dataconservancy:project-pom' is a snapshot (1.0.1-y2pilot-SNAPSHOT)
: Which release version should it be set to? 1.0.1-y2pilot: :
What version should the dependency be reset to for development? 1.0.1-y2pilot: : 1.0.2-y2pilot-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] version was null for commons-codec:commons-codec
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException: version was null for commons-codec:commons-codec
at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:273)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:136)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:98)
at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.simulate(CheckDependencySnapshotsPhase.java:290)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
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: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)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12 seconds
[INFO] Finished at: Mon Feb 28 10:08:25 EST 2011
[INFO] Final Memory: 19M/81M
[INFO] ------------------------------------------------------------------------
I was using release plugin version 2.0-beta-6.