Maven 2 & 3

Dependencies resolution is wrong in some cases (xfire-core:1.2.6 for example)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0.10
  • Fix Version/s: 2.1.0-M1
  • Component/s: Dependencies
  • Labels:
    None
  • Environment:
    2.0.10-RC1
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

With RC1, maven tries to download this dependency org/apache/ws/commons/XmlSchema/SNAPSHOT/XmlSchema-SNAPSHOT.jar whereas with 2.0.9 it retreives the version 1.1.
What I have is a project with a dependency to org.codehaus.xfire:xfire-core:1.2.6
In the xfire-core pom we have a dependency to org.apache.ws.commons:XmlSchema
The version 1.1 is set in the dependencyManagement of the parent.

A testcase is attached

Issue Links

Activity

Hide
John Casey added a comment -

This is a quirk of a bad POM:

http://repo1.maven.org/maven2/org/apache/ws/commons/XmlSchema/1.1/XmlSchema-1.1.pom

Take a look at the version string inside that POM.

I'm adjusting the MavenMetadataSource to take groupId/artifactId/version from the (potentially relocated) artifact instead of the (potentially relocated) project instance, which should clear this up for consumers of this bad metadata.

Show
John Casey added a comment - This is a quirk of a bad POM: http://repo1.maven.org/maven2/org/apache/ws/commons/XmlSchema/1.1/XmlSchema-1.1.pom Take a look at the version string inside that POM. I'm adjusting the MavenMetadataSource to take groupId/artifactId/version from the (potentially relocated) artifact instead of the (potentially relocated) project instance, which should clear this up for consumers of this bad metadata.
Hide
John Casey added a comment -

got it fixed, working on coding an integration test based on this test project (making it self-contained, of course).

Show
John Casey added a comment - got it fixed, working on coding an integration test based on this test project (making it self-contained, of course).
Hide
John Casey added a comment -

use groupId/artifactId/version from resolved/relocated POM artifact rather than POM content itself, which may be wrong (if the POM landed in the repository as a result of a non-Maven release process)

Show
John Casey added a comment - use groupId/artifactId/version from resolved/relocated POM artifact rather than POM content itself, which may be wrong (if the POM landed in the repository as a result of a non-Maven release process)

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: