Issue Details (XML | Word | Printable)

Key: MNG-2873
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: John Casey
Reporter: Micah Whitacre
Votes: 6
Watchers: 7
Operations

If you were logged in you would be able to see more operations.
Maven 2 & 3

Unable to find transitive dependencies when they have been relocated.

Created: 13/Mar/07 02:57 PM   Updated: 28/Aug/08 05:30 PM   Resolved: 28/Aug/08 05:30 PM
Component/s: Artifacts and Repositories
Affects Version/s: 2.0.5
Fix Version/s: 2.1.0-M1

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive MNG2873.ZIP (6 kB)


Complexity: Intermediate


 Description  « Hide

I have two projects A and B. Project A is dependent on B. Project B has compile time on project C which is deployed to a repository, repository1. The newest version, 2.0, of project C has since been relocated from oldGroupId to newGroupId. The relocation POMs are working correctly and Project B is able to be built successfully. Project A is not dependent on anything from repository1 it does not list that repository in its own <repositories/> section. When building project A, it tries to resolve the dependencies of B which includes C. However I am currently getting errors when it tries to resolve the C. Below is an example of this error occurring. As you can see the list of remote repositories does not display repository1 as one of the repositories that was checked despite the fact that Project B listed it in its POM.

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

No versions are present in the repository for the artifact with a range [1,)
oldGroupId:projectC:jar:null

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
repo2 (http://repo.some-repo.com/repo)

If I change project B to not use a range but to instead depend on a non-relocated version of project C everything works fine and I do not get this issue at all. The other and more correct solution to this issue is to update project B to use the new groupIds however it forces me to release project B immediately since all older released versions of B are broken by using the old groupIds an this issue.



Brian Fox added a comment - 05/Mar/08 08:44 PM

can you make a sample project or IT?


John Casey added a comment - 08/Jul/08 11:17 AM

pushing this until we can get a test to reliably reproduce it.


Stephen Pack added a comment - 27/Aug/08 05:19 PM - edited

These projects demonstrate the issue. I'm using maven 2.0.9.

It contains 3 projects – "zebra", "monkey", and "giraffe" – and uses 2 repositories – "zoo" and "wild".

*Deploy zebra (to zoo)
*Move zebra to a new groupId within zoo & deploy relocation POM
*Delete zebra from local repo
*Deploy monkey (to wild)
*Verify giraffe, which depends on monkey – zebra isn't resolved. The problem appears to be the relocation POM for zebra in zoo isn't even being read.

[DEBUG] animals:giraffe:jar:1.0 (selected for null)
[DEBUG] animals:monkey:jar:1.0:compile (selected for compile)
[DEBUG] animals:zebra:jar:1.0:compile (selected for compile)
[DEBUG] Trying repository wild-repo
Downloading: file://c:/test/repo2/animals/zebra/1.0/zebra-1.0.jar
[DEBUG] Unable to get resource 'animals:zebra:jar:1.0' from repository wild-repo (file://c:/test/repo2)
[DEBUG] Trying repository zoo-repo
Downloading: file://c:/test/repo/animals/zebra/1.0/zebra-1.0.jar
[DEBUG] Unable to get resource 'animals:zebra:jar:1.0' from repository zoo-repo (file://c:/test/repo)
[DEBUG] Trying repository central
Downloading: http://repo1.maven.org/maven2/animals/zebra/1.0/zebra-1.0.jar
[DEBUG] Unable to get resource 'animals:zebra:jar:1.0' from repository central (http://repo1.maven.org/maven2)
[DEBUG] Unable to download the artifact from any repository


luke w patterson added a comment - 27/Aug/08 09:48 PM

Have you tried 2.0.10-RC11 [1]?

Even though the scenario you described is a little different than MNG-3380, I think that fix will cover this too.

[1] - http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/


Stephen Pack added a comment - 28/Aug/08 09:11 AM

Thanks Luke! I verified with my initial, more complex use case that RC11 solves this issue.


John Casey added a comment - 28/Aug/08 05:30 PM

reported as fixed by fix for issue MNG-3380.