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