Hi John, I described the testcase and attached a sample to reproduce it. Let me know if it fails like me.
Arnaud On Wed, Apr 29, 2009 at 11:28 PM, Arnaud HERITIER <[email protected]>wrote: > Yes I can produce one tomorrow. > Arnaud > > > On Wed, Apr 29, 2009 at 11:17 PM, John Casey <[email protected]>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 <[email protected]> >>> 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 <[email protected]> >>>>> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Arnaud > -- Arnaud
