Maven 2 & 3

Having any active profiles causes the build to fail

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Resolution: Fixed
  • Affects Version/s: 2.0.6
  • Fix Version/s: 2.0.7
  • Component/s: Dependencies
  • Labels:
    None
  • Complexity:
    Intermediate
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

(This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I have any active profiles when building certain projects in Maven 2.0.6, the build will fail. For example, adding something as simple as:

<profiles>
<profile>
<id>foo</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
</profiles>

...to my ~/.m2/settings.xml file will cause the stack trace below, but the build will succeed once I remove it. I'm attaching my POM for reference.

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75)
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)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397)
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:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
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)

  1. Text File
    MNG-2923-maven-artifact.patch
    06/Apr/07 10:01 AM
    3 kB
    Allan Shoup
  2. XML File
    pom.xml
    03/Apr/07 9:00 AM
    9 kB
    Matthew Beermann

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-2929 NPE in DefaultArtifactCollector.recurse

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-2861 NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.

  • Major - Major loss of function.
  • 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-2928 Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,)

  • 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
Carlos Sanchez added a comment -

There's a test case in MNG-2923 that causes the same NPE

Show
Carlos Sanchez added a comment - There's a test case in MNG-2923 that causes the same NPE
Hide
Permalink
Allan Shoup added a comment -

Carlos, I assume you meant MNG-2929.

Show
Allan Shoup added a comment - Carlos, I assume you meant MNG-2929 .
Hide
Permalink
Micah Whitacre added a comment -

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.

Show
Micah Whitacre added a comment - 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.
Hide
Permalink
Micah Whitacre added a comment -

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
2. projectA:[1,3):compile depth of 3
3. projectA:[1,2):test depth of 2
4. projectA:[1,2):compile depth of 3.

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?

Show
Micah Whitacre added a comment - 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 2. projectA:[1,3):compile depth of 3 3. projectA:[1,2):test depth of 2 4. projectA:[1,2):compile depth of 3. 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?
Hide
Permalink
Allan Shoup added a comment -

In the scenario represented in MNG-2929, the problem appears to be a result of the VersionRange supplied to VersionRange.restrict having no restrictions and a recommended ArtifactVersion. The recommended version of the supplied VersionRange is ignored in this situation. "MNG-2923-maven-artifact.patch" will cause the specified VersionRange's recommended version to be used if the original VersionRange doesn't have a recommended version. Doing so resolves the scenario in question.

I'm not quite sure why the recommended version range of the original VersionRange takes precedence, however. Can someone elaborate on this?

Show
Allan Shoup added a comment - In the scenario represented in MNG-2929 , the problem appears to be a result of the VersionRange supplied to VersionRange.restrict having no restrictions and a recommended ArtifactVersion. The recommended version of the supplied VersionRange is ignored in this situation. " MNG-2923 -maven-artifact.patch" will cause the specified VersionRange's recommended version to be used if the original VersionRange doesn't have a recommended version. Doing so resolves the scenario in question. I'm not quite sure why the recommended version range of the original VersionRange takes precedence, however. Can someone elaborate on this?
Hide
Permalink
Micah Whitacre added a comment -

Allan's patch actually fixes my issues both with an activeProfile set and without. So +1 for me.

Show
Micah Whitacre added a comment - Allan's patch actually fixes my issues both with an activeProfile set and without. So +1 for me.
Hide
Permalink
Jason van Zyl added a comment -

I'm testing out this patch now on the trunk and branch. It looks like some MNG-1577 work at play.

Show
Jason van Zyl added a comment - I'm testing out this patch now on the trunk and branch. It looks like some MNG-1577 work at play.
Hide
Permalink
Jason van Zyl added a comment -

Patch applied.

Show
Jason van Zyl added a comment - Patch applied.
Hide
Permalink
David Greenberg added a comment -

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.

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

People

  • Assignee:
    Unassigned
    Reporter:
    Matthew Beermann
Vote (8)
Watch (7)

Dates

  • Created:
    Updated:
    Resolved: