maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud HERITIER <aherit...@gmail.com>
Subject Re: MNG-3553 may not have a viable solution in Maven 2.x
Date Wed, 29 Apr 2009 21:28:35 GMT
Yes I can produce one tomorrow.
Arnaud


On Wed, Apr 29, 2009 at 11:17 PM, John Casey <jdcasey@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 <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
>
>


-- 
Arnaud

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message