Maven 2 & 3

i get this when building a project that uses spring-hibernate3-2.0.6 all my other projects seem to be fine

it seems the problem lies somewhere in relation to ranges in the transistions...

i had a dependency on hibernate [3.1.3] in a depeedncy of the project and this causes the spring-hibernate3-2.0.6 resolution to fail... not sure why...

setting the transition to 3.1.3 fixed it for now

We are facing the same problem with ranges when we upgraded from 2.0.4 to 2.0.7. The former seems to be working fine. Our pom(s) are organized in the following manner:

/ProjectA
/pom.xml
/ProjectB
/pom.xml
/pom.xml

Project A has the following dependency:

<dependency>
<groupId>dom4j</groupId>
<artifactId>dom4j</artifactId>
<version>[1.6,)</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>[2.6.2,)</version>
<scope>compile</scope>
</dependency>

Project B's pom.xml specifies a dependency on Project A. When I have a dependency declared in Project A with a range specified for the version. For eg. [1.6,), I get the exception shown above while compiling of installing ProjectB with Maven 2.0.7.

With maven 2.0.6 I get an unable to resolve dependency error showing the below error:

Missing:
----------
1) xerces:xercesImpl:jar:RELEASE

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \
-Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file

Path to dependency:
1) ProjectB
2) commons-configuration:commons-configuration:jar:1.2
3) xerces:xercesImpl:jar:RELEASE

2) dom4j:dom4j:jar:RELEASE

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=dom4j -DartifactId=dom4j \
-Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file

Path to dependency:
1) ProjectB
2) commons-configuration:commons-configuration:jar:1.2
3) dom4j:dom4j:jar:RELEASE

Looks like a dependency resolution problem when evaluating ranges.

In commons-configuration the dependency for dom4j & xerces in its pom.xml seems to be as follows:

<dependency>
<groupId>dom4j</groupId>
<artifactId>dom4j</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xerces</artifactId>
<version>2.2.1</version>
</dependency>

We have also hit this problem in our environment. All of our projects have a mix of internal and external dependencies

Running: "mvn clean install" on Project A caused the problem. Running "mvn dependency:resolve" also causes the problment

In our case we isolated our problem to a change in the version dependencies of our internal project

WORKING CASE:

Project A depends directly on exact version 1.2.4 of Project B
Project A depends directly on exact version 1.1.2 of Project C
Project C depends directly on exact version 1.2.4 of Project B

i.e. Project A, and it's dedendency C, both agree on the specific version of B required.

FAILING CASE 1:

We build a new version of Project B to make it vesion 1.2.5
We change the Project A dependency to depend on version 1.2.5 of Project B
Project A depends directly on exact version 1.1.2 of Project C
Project C continues to depend directly on exact version 1.2.4 of Project B

The difference in version now triggers the getTrail error

FAILING CASE 2:

We change the Project A dependency to depend on version 1.2.5 of Project B
We update Project C to depend on range of Project B i.e. [1.2.5,) and we rebuild Project C to create version 1.1.3 (i.e. new build just to change the dependency)
We update Project A to depent directly on exact version 1.1.3 of Project C

I was expecting this to work, but it still triggers the getTrail exception

TEMPORARY RESOLUTION

Building on failing case 2, I:

Updated Project A to depend on a range of Project B i.e. [1.2.5,) instead of 1.2.5
Updated Project A to depend on a range of Project C i.e. [1.1.3,) instead of 1.1.3

This now works correctly.

Whoever gets assigned to this bug - keep up the great work.

Please create a core IT for this. http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test

There's a small workaround for this bug.

org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136)

replate initial code
String version = artifact.getSelectedVersion().toString();
artifact.selectVersion( version );
with:
// set the recommended version
if(artifact.getSelectedVersion()==null) { throw new RuntimeException("selected version is null:" + artifact.getArtifactId()); }

String version = artifact.getSelectedVersion().toString();
artifact.selectVersion( version );

After that Maven will throw definitive exception instead of NPE in this case, thus you could find out which dependency was the actual reason.

In my case the problem was in commons-digester [1.6) - I just added the exact version 1.7 to the root POM's dependencyManagement and maven does not fail any more.

Hope that will help

Some more information, although I am still learning my way through M2 code.

Egor, thanks for the idea of adding debug to a local build. For general information, the above workaround doesn't work with 2.0.9-SNAPSHOT code; the error doesn't get to that location (although I'm pretty sure it's ultimately the same error.) I was able to sneak in some debug in DefaultArtifact.setBaseVersionInternal to catch a null before it throws an NPE:

if ( checkScopeUpdate( farthest, nearest, listeners ) )
{
// if we need to update scope of nearest to use farthest scope, use the nearest version, but farthest scope
nearest.disable();
if (nearest.getArtifact().getVersion() == null) { throw new NullPointerException("nearest artifact has null version so setVersion will error: nearest: " + nearest + "; farthest: " + farthest); }
farthest.getArtifact().setVersion( nearest.getArtifact().getVersion() );

Because now in artifact.setVersion there's a regex Matcher that throws an NPE if the nearest artifact's version is null.

This happens when the "nearest" artifact is a ranged-version dependency. In this case, the immediate work-around was to create an explicit dependency on the "farthest version" AT THE TOP of the <dependencies> list, so that it overrides the ranged dependency before a transitive dependency resolution runs into this problem.

This should probably be either filed as a separate bug more directly implicating ranged transitive dependencies, or the name of this bug should be changed. If Maven developers need any more info I can try to provide some, but as much time as I've sunk into tracking this down, I'm short on time to file a test case at the moment.

I just got bitten by this bug with version 2.0.8. As a temporary workaroundI rolled back to version 2.0.6 and the build worked.

Whoops, I think I need to be a bit more specific...

I'm running maven version 2.0.8 and tried using maven-ant-tasks-2.0.8.jar. I tried to build a project using Ant which in-turn references a Maven pom.xml file. With maven-ant-tasks-2.0.8, I get the dreaded NPE at org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136).

If I use maven-ant-tasks-2.0.6.jar with Maven 2.0.8 the NPE goes away.

Fixed. See comments in MNG-2123 for possible workaround in the meantime.