|
Carlos, I assume you meant
I am encountering this issue both when I have an active profile set and when I do not. I haven't debugged fully to see how active profiles play into some of my projects passing but I have debugged through a few times for projects that always throw NPE.
It seems what is happening is that when building the project it is resolving all of the dependencies. A dependency is resolved multiple times because it is transitively resolved from different projects. As it is resolving the dependencies it is encountering different version ranges [1,2) and [1,3). As it determines the version it wants, enables and disables artifacts, it then restricts the version of the artifact it wants so that the version is set to 1.2 (the one available) but it restricts the versionRange of the artifact to be []. So the next time transitively finds the dependency on line 164 (the NPE) line it tries to find a version that matches the version range of []. It therefore can't find a match and then dies on the toString() call. I haven't broken this down to a simple reproduceable workflow but that is the flow that is causing it to die even without the <activeProfiles/> in the settings.xml file. Ok so I tracked this down again and am now going to try and see if I can explain it.
I have a project that transitively inherits a project from multiple locations. Here is an example of the setup: 1. projectA:[1,3):test depth of 4 The version that should be resolved is 1.2 which is valid for all of those ranges. When resolving the dependencies it resolves them in that order. By the time it is resolving the 3 instances the first instance has already been disabled. So when it is resolving the 3 instance it determines that based on the scopes it should enable 2 and disable 3. On line 193 of DefaultArtifactCollector it sets the version of the farthest (instance 2). Calling DefaultArtifact.setVersion(String) sets the versionRange of the artifact to null. When trying to find a match for the versionRange when trying to resolve instance 4, on line 164 of DefaultArtifactCollector it can't find a match for instance 2 now because its range is null. So then it throws the NPE on the toString() call. Why is calling setVersion clearing out the versionRange? Shouldn't it be acceptable to have both specified? In the scenario represented in
I'm not quite sure why the recommended version range of the original VersionRange takes precedence, however. Can someone elaborate on this? Allan's patch actually fixes my issues both with an activeProfile set and without. So +1 for me.
I'm testing out this patch now on the trunk and branch. It looks like some
I am a beginner with Maven, and am getting this issue with Maven 2.0.9. What's weird is that I didn't have this issue for the few months that I have been using this configuration, and suddenly it broke today. Is there an easy way to tell which dependency it is breaking on? I have a lot of dependencies in my pom.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Having any active profiles causes the build to fail
MNG-2923that causes the same NPE