You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2009/04/23 19:50:28 UTC
MNG-3553 may not have a viable solution in Maven 2.x
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
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <ah...@gmail.com>wrote:
> Yes I can produce one tomorrow.
> Arnaud
>
>
> On Wed, Apr 29, 2009 at 11:17 PM, John Casey <jd...@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 <jd...@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 <jd...@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
>
--
Arnaud
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by Arnaud HERITIER <ah...@gmail.com>.
Yes I can produce one tomorrow.
Arnaud
On Wed, Apr 29, 2009 at 11:17 PM, John Casey <jd...@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 <jd...@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 <jd...@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
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by John Casey <jd...@commonjava.org>.
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 <jd...@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 <jd...@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
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <jd...@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 <jd...@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
>
>
--
Arnaud
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by John Casey <jd...@commonjava.org>.
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 <jd...@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
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <jd...@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
>
>
--
Arnaud
Re: MNG-3553 may not have a viable solution in Maven 2.x
Posted by Ralph Goers <ra...@dslextreme.com>.
First, I greatly appreciate you taking the time to look into this.
I've been so busy working on another project that as much as I have
intended to debug this, I just haven't had a chance.
If the problem is as you say then I'm not sure it should be fixed. But
the issue I heard reported was that people were trying to use a
repository other than central and it wasn't going there. I suspect
that I simply didn't add in the correct repositories on one of the
calls and it is just using the default.
Ralph
On Apr 23, 2009, at 10:50 AM, John Casey 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