You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Gier <pg...@redhat.com> on 2008/05/22 16:28:09 UTC
Pom changes in 2.1 (was Re: dependency version conflict resolution)
Improved dependency version conflict resolution, and a lot of other important
issues either require or would benefit from changing the pom model. As far as I
can tell, there have not yet been any changes to this model in the 2.1 branch.
So I was wondering what should be the strategy for changes in the future?
Brian brought up the issue that if we change the model and start deploying
artifacts to the repository that use the new poms, then there may be some
incompatibility if the dependency tree contains a mix of older and newer poms.
So the remaining choices appear to be either start a new repository or never
change the pom model.
So can we make changes to the model in 2.1, or do we have to work with the
existing model?
Mark Hobson wrote:
> Yep, my ongoing saga with conflict resolution is detailed here:
>
> http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
> http://jira.codehaus.org/browse/MNG-612
>
> Would be great to get this resolved.
>
> Mark
>
> 2008/5/22 Brett Porter <br...@apache.org>:
>> That's what I was referring to.
>>
>> On 22/05/2008, at 10:25 AM, Brian E. Fox wrote:
>>
>>> I thought Mark already started this and/or has a proposal on the wiki.
>>>
>>> -----Original Message-----
>>> From: Brett Porter [mailto:brett.porter@gmail.com] On Behalf Of Brett
>>> Porter
>>> Sent: Wednesday, May 21, 2008 8:11 PM
>>> To: Maven Developers List
>>> Subject: Re: dependency version conflict resolution
>>>
>>> Hi John,
>>>
>>> I don't think there's any objection to implementing this strategy -
>>> however it's something that needs to be done in a pluggable way so
>>> that current build behaviour doesn't change. This has a few
>>> dependencies on other work in the core.
>>>
>>> Some people who are interested have contributed towards this in the
>>> past. Is this something you are looking to work on, or just making a
>>> request?
>>>
>>> Thanks,
>>> Brett
>>>
>>> On 22/05/2008, at 5:36 AM, John Williams wrote:
>>>
>>>> I'm new to list list so I apologize if this has been beaten to death
>>>> before, but I'd like to propose a change to the version conflict
>>>> resolution strategy that Maven uses. It's a combination of the
>>>> current "nearest version" strategy and a "highest version" strategy.
>>>> There are two cases:
>>>>
>>>> 1. When an artifact has a declared dependency, the declared version
>>>> always takes precedence over any inherited version.
>>>> 2. When a project inherits two versions of the same dependency, the
>>>> highest-numbered version takes precedence.
>>>>
>>>> Rule 1 is consistent with the "nearest" strategy. It is necessary to
>>>> give developers adequate control over the dependencies they use, and
>>>> also because it would be very confusing for Maven to use an artifact
>>>> version other than the one declared in the pom.xml file. I believe
>>>> this rule preserves all the desirable features of the "nearest"
>>>> strategy.
>>>>
>>>> Rule 2 is consistent with a "highest" strategy, and it addresses the
>>>> problem of unrelated artifacts overriding each other's dependencies.
>>>> Suppose artifact A depends on B and C, both of which depend on
>>>> different versions of D (and A does not depend directly on D).
>>>> Obviously either B or C will be forced for use a version of D for
>>>> which it was not designed, but if the developer of D has made some
>>>> attempt to preserve compatibility across versions, the higher-numbered
>>>> version of D is far more likely to work with both B and C and the
>>>> lower-numbered version. I think this would be a big improvement over
>>>> the somewhat arbitrary decision that the "nearest" strategy would
>>>> make.
>>>>
>>>> --jw
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> 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: Pom changes in 2.1 (was Re: dependency version conflict resolution)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>> So can we make changes to the model in 2.1, or do we have to work
>> with the existing model?
>>
>Provide we retain the behavior of old with a flag if the user desires
>with 2.1 the door is wide open to correct anything we see fit.
It's more than that, the poms deployed to central should conform to the
4.0.0 format or no one will be able to use them. Since not a lot of info
is needed when depending on an artifact, this should be doable without
any loss of resolution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pom changes in 2.1 (was Re: dependency version conflict resolution)
Posted by Jason van Zyl <ja...@maven.org>.
On 22-May-08, at 7:28 AM, Paul Gier wrote:
> Improved dependency version conflict resolution, and a lot of other
> important issues either require or would benefit from changing the
> pom model. As far as I can tell, there have not yet been any
> changes to this model in the 2.1 branch. So I was wondering what
> should be the strategy for changes in the future?
>
> Brian brought up the issue that if we change the model and start
> deploying artifacts to the repository that use the new poms, then
> there may be some incompatibility if the dependency tree contains a
> mix of older and newer poms. So the remaining choices appear to be
> either start a new repository or never change the pom model.
>
> So can we make changes to the model in 2.1, or do we have to work
> with the existing model?
>
Provide we retain the behavior of old with a flag if the user desires
with 2.1 the door is wide open to correct anything we see fit.
>
>
> Mark Hobson wrote:
>> Yep, my ongoing saga with conflict resolution is detailed here:
>> http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
>> http://jira.codehaus.org/browse/MNG-612
>> Would be great to get this resolved.
>> Mark
>> 2008/5/22 Brett Porter <br...@apache.org>:
>>> That's what I was referring to.
>>>
>>> On 22/05/2008, at 10:25 AM, Brian E. Fox wrote:
>>>
>>>> I thought Mark already started this and/or has a proposal on the
>>>> wiki.
>>>>
>>>> -----Original Message-----
>>>> From: Brett Porter [mailto:brett.porter@gmail.com] On Behalf Of
>>>> Brett
>>>> Porter
>>>> Sent: Wednesday, May 21, 2008 8:11 PM
>>>> To: Maven Developers List
>>>> Subject: Re: dependency version conflict resolution
>>>>
>>>> Hi John,
>>>>
>>>> I don't think there's any objection to implementing this strategy -
>>>> however it's something that needs to be done in a pluggable way so
>>>> that current build behaviour doesn't change. This has a few
>>>> dependencies on other work in the core.
>>>>
>>>> Some people who are interested have contributed towards this in the
>>>> past. Is this something you are looking to work on, or just
>>>> making a
>>>> request?
>>>>
>>>> Thanks,
>>>> Brett
>>>>
>>>> On 22/05/2008, at 5:36 AM, John Williams wrote:
>>>>
>>>>> I'm new to list list so I apologize if this has been beaten to
>>>>> death
>>>>> before, but I'd like to propose a change to the version conflict
>>>>> resolution strategy that Maven uses. It's a combination of the
>>>>> current "nearest version" strategy and a "highest version"
>>>>> strategy.
>>>>> There are two cases:
>>>>>
>>>>> 1. When an artifact has a declared dependency, the declared
>>>>> version
>>>>> always takes precedence over any inherited version.
>>>>> 2. When a project inherits two versions of the same dependency,
>>>>> the
>>>>> highest-numbered version takes precedence.
>>>>>
>>>>> Rule 1 is consistent with the "nearest" strategy. It is
>>>>> necessary to
>>>>> give developers adequate control over the dependencies they use,
>>>>> and
>>>>> also because it would be very confusing for Maven to use an
>>>>> artifact
>>>>> version other than the one declared in the pom.xml file. I
>>>>> believe
>>>>> this rule preserves all the desirable features of the "nearest"
>>>>> strategy.
>>>>>
>>>>> Rule 2 is consistent with a "highest" strategy, and it addresses
>>>>> the
>>>>> problem of unrelated artifacts overriding each other's
>>>>> dependencies.
>>>>> Suppose artifact A depends on B and C, both of which depend on
>>>>> different versions of D (and A does not depend directly on D).
>>>>> Obviously either B or C will be forced for use a version of D for
>>>>> which it was not designed, but if the developer of D has made some
>>>>> attempt to preserve compatibility across versions, the higher-
>>>>> numbered
>>>>> version of D is far more likely to work with both B and C and the
>>>>> lower-numbered version. I think this would be a big improvement
>>>>> over
>>>>> the somewhat arbitrary decision that the "nearest" strategy would
>>>>> make.
>>>>>
>>>>> --jw
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org