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 > > -- Arnaud
