maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <jdca...@commonjava.org>
Subject Re: MNG-3553 may not have a viable solution in Maven 2.x
Date Wed, 29 Apr 2009 21:17:09 GMT
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 <jdcasey@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 <jdcasey@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message