Maven 2 & 3

Transitive Dependency not found when repo is not listed

Details

  • Number of attachments :
    2

Description

I have seen the situation where a build fails because a project has a transitive dependency that only exists in a repository not listed by my project. An example of this is I have Projects A, B, and C. Where A depends on B, and B on C. B has been released to remote repo 1, and C has been released to remote repo 2. Since A just directly depends on B it only lists remote repo 1 in its POM. However when I try to build project A the build fail because it can't resolve its transitive dependency C in any of the dependencies it is checking (repo 1 only).

It is my understanding that for project A I shouldn't have to list the remote repos to resolve transitive dependencies. I should only have to list the repos to get to B and Maven then should use the POM of B to resolve C.

Is that not correct?

Issue Links

This issue is related to:
MNG-3056 Dependencies should not be able to introduce repositories to the build Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason van Zyl added a comment -

Incomplete provide a sample build to illustrate the problem.

Show
Jason van Zyl added a comment - Incomplete provide a sample build to illustrate the problem.
Hide
Permalink
Dirk Olmes added a comment -

This example does not exactly reproduce the described setup but illustrates the same effect. The toplevel pom defines a repository, module 'foo' defines two other repositories and module 'bar' depends on 'foo' and on artifacts that can be resolved from bar's repository.

The point is here that if you define a dependency you should be able to resolve transient dependencies through the inherited repositories.

Show
Dirk Olmes added a comment - This example does not exactly reproduce the described setup but illustrates the same effect. The toplevel pom defines a repository, module 'foo' defines two other repositories and module 'bar' depends on 'foo' and on artifacts that can be resolved from bar's repository. The point is here that if you define a dependency you should be able to resolve transient dependencies through the inherited repositories.
Hide
Permalink
Micah Whitacre added a comment -

I hacked up Dirk's example (thanks for giving me a starting point) and created an example that illustrates my point. Inside the zip file you will find three projects, foo, bar, and wombat. Wombat depends on Bar which depends on Foo. Using the projects in the zip file, run "mvn clean deploy" on foo and then bar. After that is completed clear out your local repository and try and run "mvn clean compile" on wombat. It will have an issue being able to resolve foo and I get the following output:

Missing:
----------
1) org.mule:mule-foo:jar:1.0-SNAPSHOT

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.mule -DartifactId=mule-foo -Dversio
n=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:

mvn deploy:deploy-file -DgroupId=org.mule -DartifactId=mule-foo -Dversion=
1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id
]

Path to dependency:
1) org.mule:mule-wombat:jar:1.0-SNAPSHOT
2) org.mule:mule-bar:jar:1.0-SNAPSHOT
3) org.mule:mule-foo:jar:1.0-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
org.mule:mule-wombat:jar:1.0-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
example2-repo (file://c:/test/repo2)

You'll notice that it never lists example1-repo as a repository it checked to find foo.

Show
Micah Whitacre added a comment - I hacked up Dirk's example (thanks for giving me a starting point) and created an example that illustrates my point. Inside the zip file you will find three projects, foo, bar, and wombat. Wombat depends on Bar which depends on Foo. Using the projects in the zip file, run "mvn clean deploy" on foo and then bar. After that is completed clear out your local repository and try and run "mvn clean compile" on wombat. It will have an issue being able to resolve foo and I get the following output: Missing: ---------- 1) org.mule:mule-foo:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.mule -DartifactId=mule-foo -Dversio n=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.mule -DartifactId=mule-foo -Dversion= 1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id ] Path to dependency: 1) org.mule:mule-wombat:jar:1.0-SNAPSHOT 2) org.mule:mule-bar:jar:1.0-SNAPSHOT 3) org.mule:mule-foo:jar:1.0-SNAPSHOT ---------- 1 required artifact is missing. for artifact: org.mule:mule-wombat:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), example2-repo (file://c:/test/repo2) You'll notice that it never lists example1-repo as a repository it checked to find foo.
Hide
Permalink
Micah Whitacre added a comment -

reopening because I provided a complete example that illustrates the issues we are seeing.

Show
Micah Whitacre added a comment - reopening because I provided a complete example that illustrates the issues we are seeing.
Hide
Permalink
luke w patterson added a comment -

In 2.0.8, it only worked for me after I modified <distributionManagement> to include <uniqueVersion>false</uniqueVersion>.

In 2.0.9, it seems to work ok without modifications.

Show
luke w patterson added a comment - In 2.0.8, it only worked for me after I modified <distributionManagement> to include <uniqueVersion>false</uniqueVersion>. In 2.0.9, it seems to work ok without modifications.
Hide
Permalink
John Casey added a comment -

Need to incorporate an integration test for this issue to verify that it's fixed.

Show
John Casey added a comment - Need to incorporate an integration test for this issue to verify that it's fixed.
Hide
Permalink
John Casey added a comment -

The problem is that the DefaultArtifactCollector is not using the repository list aggregated and associated with each dependency is read via the MavenMetadataSource...instead, it's using the repository list that was used to resolve the declaring POM (the one that listed those dependencies).

I've corrected it and verified by hand that it works with the attached test project, but I still need to convert the attached test project into a self-contained integration-test project before I close this issue.

Show
John Casey added a comment - The problem is that the DefaultArtifactCollector is not using the repository list aggregated and associated with each dependency is read via the MavenMetadataSource...instead, it's using the repository list that was used to resolve the declaring POM (the one that listed those dependencies). I've corrected it and verified by hand that it works with the attached test project, but I still need to convert the attached test project into a self-contained integration-test project before I close this issue.
Hide
Permalink
John Casey added a comment -

It appears that this problem is NOT expressed unless the dependencies are snapshots (not sure whether they both have to be, but when they both are, the problem happens)...if I change them both to non-snapshot versions, the problem disappears...

Show
John Casey added a comment - It appears that this problem is NOT expressed unless the dependencies are snapshots (not sure whether they both have to be, but when they both are, the problem happens)...if I change them both to non-snapshot versions, the problem disappears...

People

Vote (2)
Watch (8)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.