|
[
Permalink
| « Hide
]
Carlos Sanchez added a comment - 06/Mar/06 01:38 AM
if I add a dependency to commons-digester 1.7 it works
if I add a dependency in 1.6 it breaks, so I can't force a version in my pom
Maven version: 2.0.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: Path to dependency: commons-digester:commons-digester:jar:RELEASE [INFO] ---------------------------------------------------------------------------- Missing: Try downloading the file manually from the project website. Then, install it using the command: Path to dependency: ---------- for artifact: from the specified remote repositories: [INFO] ---------------------------------------------------------------------------- Try downloading the file manually from the project website. Then, install it using the command: Path to dependency: ---------- for artifact: from the specified remote repositories: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) Try downloading the file manually from the project website. Then, install it using the command: Path to dependency: ---------- for artifact: from the specified remote repositories: at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:244) I found the cause of the NPE when a created the unit test for it. Unfortunately, when I tried fixing it, a different unit test failed... meaning it is an expected behavior to return null when the merged restrictions are conflicting. I'll then have to catch the returned null and throw a more informative exception in the calling class.
As Brett suggested, I'm just going to make RELEASE as the default recommendationVersion so that it will be returned for conflicting VersionRanges. I've now made the unit tests pass and will be doing intensive tests on it for the different projects I have.
I'm attaching the patch for this. I changed the default recommendation to RELEASE in case restrict does not find a valid version. Also changed the unit tests, since the tests show that null is expected which causes this bug.
Any one of the voters/watchers care to make an IT for this? http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test
Making a second call for ITs:
Any one of the voters/watchers care to make an IT for this? http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test This may have been fixed in trunk, i remember having seen a OverConstrainedVersionException
At least since
Integration test.
The test creates two artifacts with a dependency to commons-collection. artifact-fix requires version 3.2 artifact-range requires version (2.0,3.1.99] artifact-combined has a dependency on the artifacts above. The proposed fix is to return RELEASE as the version if two dependencies at the same level specify incompatible versions (ie 3.2 and (2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning the RELEASE version feels wrong. First that totally breaks repeatability of a build and second, shouldn't we notify the user with a useful exception instead of guessing anything? (discussion on @ dev: http://www.nabble.com/Comments-on-MNG-2123-%28version-specification-issues%29-td15810087s177.html Tried the pom.xml I've attached the first time and the error is still present in 2.0.9 and 2.1.
The expected behaviour would be to throw an OverConstrainedVersionException The IT test shows a slightly different stack trace than the original pom uploaded
In 2.0.9-SNAPSHOT java.lang.NullPointerException In 2.1-SNAPSHOT java.lang.NullPointerException Fixed so that the correct version is selected from the range, without shoving RELEASE anywhere. The issue only happened if the first instance of the offending artifact was not a range, but the second instance was. Based on my unit testing, reversing the order of your dependencies in the pom should work around this until 2.0.9
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||