was the settings-injected repository in a profile that was marked in
<activeProfiles> ?
Just trying to get an idea how to replicate.
Arnaud HERITIER wrote:
Hi John,
Thanks to try to fix this.
I have this issue but in my case I don't define any repository in my
projects. I override the central definition in my user's settings to use our
corporate repo. This method always works to build projects except when I'm
using imports : Maven tries to download dependencies from the real central.
Why my settings doesn't override it ?
To fix I had to use a proxy * to always use the corporate repo. Personnaly
I don't like that because I had to merge in the same group, releases and
snapshots.
I have no idea to fix it but :
- I don't want to define my corporate repository in all poms
- It's really annoying today to have only this case which doesn't work
when we override the central repo definition.
Arnaud
On Thu, Apr 23, 2009 at 7:50 PM, John Casey <jdca...@commonjava.org> 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
