First, I greatly appreciate you taking the time to look into this.
I've been so busy working on another project that as much as I have
intended to debug this, I just haven't had a chance.
If the problem is as you say then I'm not sure it should be fixed. But
the issue I heard reported was that people were trying to use a
repository other than central and it wasn't going there. I suspect
that I simply didn't add in the correct repositories on one of the
calls and it is just using the default.
Ralph
On Apr 23, 2009, at 10:50 AM, John Casey wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
