Maven 2 & 3

NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.5
  • Fix Version/s: 2.0.9
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    3

Description

In a remoteRepository that I am populating I have a project. Previously I was deploying artifacts with an old groupId and then decided to switch to having a new more descriptive groupId. For the old groupId I have deployed versions 1.0 and 1.1. For the new groupId I have deployed 1.2 and 2.0. I deployed a relocation POM to the old groupId for the 1.2 version. I also updated the metadata.xml files to include 1.2 as an available version. This way projects using version ranges [1,2) will be able to pick up the newest version. So in the repository I now have:

oldgroupId:project:1.0
oldgroupId:project:1.1
oldgroupId:project:1.2 - redirecting to newgroupId:project:1.2
newgroupId:project:1.2
newgroupId:project:2.0

The oldgroupId's metadata lists the available versions as [1.0,1.1,1.2]. The newgroupId's metadata lists the available versions has [1,2].

I have 3 additional projects A, B, C. A depends on B and C. B depends on oldgroupId:project:[1,2). Project B has also finished development and been released so we are avoiding rereleasing it for the groupId change. C depends on newgroupId:project:[2,3). When I try to build project A, Maven dies and gives me the following stack trace.

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
java.lang.NullPointerException
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:168)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1142)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:374)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:585)
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)

Since the key for common dependency is the same it tries to resolve the dependency by restricting the version ranges of the current and previous resolved artifacts. It restricts the previous version to the range of to be [2,3). However since the only available versions are [1.0,1.1,1.2] it cannot find and match and on line 168 it calls toString() on the returned match which is null.

I realize that the repository setup might not be completely correct, however this is still an issue since Maven crashes without giving any appropriate message or warning to the cause.

  2. GZip Archive
    MNG-2861.tar.gz
    21/Aug/07 1:40 AM
    11 kB
    Brett Porter
  3. Text File
    MNG-2861-maven-project.patch
    25/Jul/07 10:46 AM
    2 kB
    Matthew Beermann

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-3454 processing a relocation erases requested version range

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MNG-2923 Having any active profiles causes the build to fail

  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2123 NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Matthew Beermann added a comment -

I think that the relocations are simply exposing a latent OverConstrainedVersionException that isn't being handled properly. This patch makes Maven throw the "real" error, for me at least.

Show
Matthew Beermann added a comment - I think that the relocations are simply exposing a latent OverConstrainedVersionException that isn't being handled properly. This patch makes Maven throw the "real" error, for me at least.
Hide
Permalink
Matthew Beermann added a comment -

Er, looks like I misnamed the patch. It should be MNG-2861-maven-artifact.patch, of course.

Show
Matthew Beermann added a comment - Er, looks like I misnamed the patch. It should be MNG-2861 -maven-artifact.patch, of course.
Hide
Permalink
Brett Porter added a comment -

This would be much easier if you provide a test case... I attempted to reproduce quickly it following the example and wasn't able to (it succeeds on maven 2.0.5, 2.0.6, 2.0.7 and 2.1-SNAPSHOT). See attached test case.

Show
Brett Porter added a comment - This would be much easier if you provide a test case... I attempted to reproduce quickly it following the example and wasn't able to (it succeeds on maven 2.0.5, 2.0.6, 2.0.7 and 2.1-SNAPSHOT). See attached test case.
Hide
Permalink
Matthew Beermann added a comment -

I'm having trouble creating a minimized testcase too... but I do know that someone in our organization seems to encounter this problem almost daily. If it comes to it, I can always email you our entire repository and a project that exhibits the issue.

Other details: The stack trace has morphed slightly in recent versions of Maven, since this bug was first filed. In 2.0.7, it looks like:

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
java.lang.NullPointerException
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:197)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238)

Also, with the patch applied, the build still fails, but with a more informative error message:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Couldn't find a version in [1.6.0, 1.7, 1.7.1, 2.0] to match range [2.0-SNAPSHOT,2)

Show
Matthew Beermann added a comment - I'm having trouble creating a minimized testcase too... but I do know that someone in our organization seems to encounter this problem almost daily. If it comes to it, I can always email you our entire repository and a project that exhibits the issue. Other details: The stack trace has morphed slightly in recent versions of Maven, since this bug was first filed. In 2.0.7, it looks like: [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] null [INFO] ------------------------------------------------------------------------ [DEBUG] Trace java.lang.NullPointerException at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) Also, with the patch applied, the build still fails, but with a more informative error message: [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to resolve artifact. Couldn't find a version in [1.6.0, 1.7, 1.7.1, 2.0] to match range [2.0-SNAPSHOT,2)
Hide
Permalink
Micah Whitacre added a comment -

Your testcase worked for me as well. I found that there was a difference between how your relocation POMs look compared the ones that were deployed in our repo. The difference was that in your relocation POM you have the following information:

<distributionManagement>
<relocation>
<groupId>newgroupId</groupId>
<artifactId>project</artifactId>
<version>1.2</version>
</relocation>
</distributionManagement>

vs. in our relocation POMs we just have this:

<distributionManagement>
<relocation>
<groupId>newgroupId</groupId>
</relocation>
</distributionManagement>

What we have follows the minimal required POM as documented on the Maven site.[1]

The attachment includes a modified version of your repository (I didn't regenerate the checksums) so that it follows what we have. In that case I get the NPE for which this issue is logged.

[1] - http://maven.apache.org/guides/mini/guide-relocation.html

Show
Micah Whitacre added a comment - Your testcase worked for me as well. I found that there was a difference between how your relocation POMs look compared the ones that were deployed in our repo. The difference was that in your relocation POM you have the following information: <distributionManagement> <relocation> <groupId>newgroupId</groupId> <artifactId>project</artifactId> <version>1.2</version> </relocation> </distributionManagement> vs. in our relocation POMs we just have this: <distributionManagement> <relocation> <groupId>newgroupId</groupId> </relocation> </distributionManagement> What we have follows the minimal required POM as documented on the Maven site. [1] The attachment includes a modified version of your repository (I didn't regenerate the checksums) so that it follows what we have. In that case I get the NPE for which this issue is logged. [1] - http://maven.apache.org/guides/mini/guide-relocation.html
Hide
Permalink
Brian Fox added a comment -

This may be related to MNG-2123, i found the same mistake in a few places of the code. Will recheck once 2123 is fixed.

Show
Brian Fox added a comment - This may be related to MNG-2123 , i found the same mistake in a few places of the code. Will recheck once 2123 is fixed.
Hide
Permalink
Brian Fox added a comment -

putting this to 2.0.9 so I remember to look again.

Show
Brian Fox added a comment - putting this to 2.0.9 so I remember to look again.
Hide
Permalink
Brian Fox added a comment -

I was not able to reproduce using the file based repo, but when I added them to an http repo, i can reproduce in 2.0.9-SNAPSHOT....

Show
Brian Fox added a comment - I was not able to reproduce using the file based repo, but when I added them to an http repo, i can reproduce in 2.0.9-SNAPSHOT....
Hide
Permalink
Brian Fox added a comment -

fixed + IT

Show
Brian Fox added a comment - fixed + IT

People

  • Assignee:
    Brian Fox
    Reporter:
    Micah Whitacre
Vote (11)
Watch (7)

Dates

  • Created:
    Updated:
    Resolved: