Do you happen to have a test case I can use to prod at this problem a
little bit? I'm working on a mockup of the scenario you talk about, but
I'm not certain I understand it well enough to reproduce.
Arnaud HERITIER wrote:
yesA default-profil in my activeProfiles
In this profil I have 2 repositories :
- one for releases with the id central
- one for snashots with the id snapshot
Each repository is an archiva / nexus group
Arnaud
On Thu, Apr 23, 2009 at 11:56 PM, John Casey <jdca...@commonjava.org> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
