Yes I can produce one tomorrow. Arnaud
On Wed, Apr 29, 2009 at 11:17 PM, John Casey <jdca...@commonjava.org> wrote: > 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 > > -- Arnaud
