Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-318

Release plugin throws NullPointerException when using version range for dependency

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta-7
    • Fix Version/s: 2.1
    • Component/s: prepare
    • Labels:
      None
    • Flags:
      Patch

      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.

      1. MNG-3351_dependency_poms.zip
        17 kB
        Dave Hoffer
      2. MNG-3351.zip
        7 kB
        Dave Hoffer
      3. MNG-3351-unittest.patch
        13 kB
        Mark Hobson
      4. simple-testcase.zip
        2 kB
        Mark Hobson
      5. simple-test-case-console-log.txt
        5 kB
        Dave Hoffer

        Issue Links

          Activity

          Hide
          David Hoffer added a comment -

          I was using release plugin version 2.0-beta-6.

          Show
          David Hoffer added a comment - I was using release plugin version 2.0-beta-6.
          Hide
          David Hoffer added a comment -

          This bug occurs with release plugin version 2.0-beta-7 as well.

          Show
          David Hoffer added a comment - This bug occurs with release plugin version 2.0-beta-7 as well.
          Hide
          Brian E. Fox added a comment -

          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.

          Show
          Brian E. Fox added a comment - 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.
          Hide
          David Hoffer added a comment -

          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.

          Show
          David Hoffer added a comment - 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.
          Hide
          Brian E. Fox added a comment -

          This is a duplicate showing up in the dependency plugin

          Show
          Brian E. Fox added a comment - This is a duplicate showing up in the dependency plugin
          Hide
          Brian E. Fox added a comment -

          David, can we get a pom or IT test to reproduce this? There is also a pom at MNG-3372 to show this (but has many internal dependencies)

          Show
          Brian E. Fox added a comment - David, can we get a pom or IT test to reproduce this? There is also a pom at MNG-3372 to show this (but has many internal dependencies)
          Hide
          David Hoffer added a comment -

          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.

          Show
          David Hoffer added a comment - 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.
          Hide
          David Hoffer added a comment -

          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.

          Show
          David Hoffer added a comment - 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.
          Hide
          Mark Hobson added a comment -

          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.

          Show
          Mark Hobson added a comment - 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.
          Hide
          David Hoffer added a comment -

          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).

          Show
          David Hoffer added a comment - 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).
          Hide
          Mark Hobson added a comment -

          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.

          Show
          Mark Hobson added a comment - 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.
          Hide
          David Hoffer added a comment -

          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

          Show
          David Hoffer added a comment - 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
          Hide
          Mark Hobson added a comment -

          David, by carrying on the lengthy discussion on maven-dev I believe..

          Show
          Mark Hobson added a comment - David, by carrying on the lengthy discussion on maven-dev I believe..
          Hide
          Elliot Metsger added a comment -

          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.

          Show
          Elliot Metsger added a comment - 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.
          Hide
          Brett Porter added a comment -

          related to other issue, need to check if patch is still relevant

          Show
          Brett Porter added a comment - related to other issue, need to check if patch is still relevant
          Hide
          Brett Porter added a comment -

          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.

          Show
          Brett Porter added a comment - 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.
          Hide
          Arik Kfir added a comment -

          Brett, can you please elaborate about the "more general problem about ranges" you mentioned?

          Show
          Arik Kfir added a comment - Brett, can you please elaborate about the "more general problem about ranges" you mentioned?
          Hide
          Brett Porter added a comment -

          Arik, I meant the reference to the MNG-3092 issue which is still being debated.

          Show
          Brett Porter added a comment - Arik, I meant the reference to the MNG-3092 issue which is still being debated.
          Hide
          Michael McCallum added a comment -

          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.

          Show
          Michael McCallum added a comment - 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.
          Hide
          Phillip Hellewell added a comment -

          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)
          ...

          Show
          Phillip Hellewell added a comment - 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) ...
          Hide
          Michał Politowski added a comment - - edited

          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)
          [...]

          Show
          Michał Politowski added a comment - - edited 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) [...]
          Hide
          Kristoffer Peterhänsel added a comment -

          Yeah. Not working for me in Maven 2.2.1 either. Exact same stack trace as the one from Michał Politowski

          Show
          Kristoffer Peterhänsel added a comment - Yeah. Not working for me in Maven 2.2.1 either. Exact same stack trace as the one from Michał Politowski
          Hide
          Elliot Metsger added a comment -

          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

          {execution: default-cli}

          ]
          [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] ------------------------------------------------------------------------

          Show
          Elliot Metsger added a comment - 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 {execution: default-cli} ] [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] ------------------------------------------------------------------------

            People

            • Assignee:
              Brett Porter
              Reporter:
              David Hoffer
            • Votes:
              17 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development