[
http://jira.codehaus.org/browse/MNG-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Micah Whitacre updated MNG-2861:
--------------------------------
Attachment: MNG-2861_broken.zip
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
> NullPointerException in DefaultArtifactCollector for relocated
> resolvedArtifacts with different version ranges and available versions.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-2861
> URL: http://jira.codehaus.org/browse/MNG-2861
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.0.5
> Reporter: Micah Whitacre
> Fix For: 2.0.x
>
> Attachments: MNG-2861-maven-project.patch, MNG-2861.tar.gz,
> MNG-2861_broken.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
