Hi,
I've been looking into MNG-3553 and the relevant code, and I'm starting
to believe that we cannot solve the problem discussed in the issue
without breaking other functionality.
The basic problem stated in the issue is:
Given:
project A
- packaging == 'pom'
- has dependencies on X,Y,Z
- these are resolved from a custom repository, R
project B
- has project A listed in dependencyManagement with
* scope == 'import'
* type == 'pom'
- defines dependencies on X,Y,Z
* does not define versions for these
* USES VERSIONS FROM IMPORTED depMan project A.
- does NOT define custom repository R
project C
- has a dependency on project B
When building project C, it cannot resolve X,Y,Z. The root of the
problem is that when dependencies of project A are imported into depMan
for project B, the corresponding repository R is NOT imported into
project B. When project B's dependencies are resolved, Maven cannot
resolve the versions of X,Y,Z that are used from B's depMan, since
repository R is not available. If repository R is added to project B to
compensate, everything works.
It might be tempting to say, "Well, then just add in the repositories
from the imported POM." The problem here is that this could change the
way snapshot versions are resolved for dependencies that have nothing to
do with the imported POM/dependencyManagement configuration. By simply
adding these repositories from the imported POM, we would be changing
the way the rest of the build process works, and possibly destabilizing
it in completely counter-intuitive ways. If a snapshot version broke the
build and the user figured out which specific version was being used, he
might find that it's next-to impossible to figure out where that version
is coming from. It could also have an effect on the way plugins and
plugin dependencies are resolved, since transitive dependency resolution
for plugins often makes use of the repositories section in the 2+ level
stage of resolution.
Because of the above, my strong inclination is to say that propagating
these repository definitions must remain a manual task (the current
workaround detailed in the comments for MNG-3553), to avoid reducing the
transparency of the dependency-resolution process. I'd really like to
hear what others think on this issue, though...other ways we might
approach the issue, and potentially find a solution that won't make
Maven seem to be _more_ of a magical process.
Thoughts?
Thanks,
-john
---
John Casey
Developer and PMC Member, Apache Maven (http://maven.apache.org)
Member, Apache Software Foundation
Blog: http://www.ejlife.net/blogs/buildchimp
"What we have to learn to do, we learn by doing."
-Aristotle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
