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 Williams <jr...@pobox.com> on 2008/05/21 21:36:21 UTC
dependency version conflict resolution
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
Re: dependency version conflict resolution
Posted by Paul Gier <pg...@redhat.com>.
Sorry Gilles, I didn't mean to try put words in your mouth :) I probably just
read your email describing Ivy too quickly and assumed that you wanted Maven to
have similar features.
Gilles Scokart wrote:
> For the record, note that I didn't argue that maven should do the same
> than ivy. Ivy has a general philosophy of flexibility. Maven has a
> philosophy of promoting good practices.
>
> I guess that both should be consistent with their general pholosophy...
>
> But I didn't answered to the question "Is it a good practice to adapt
> your conflict manager in function of your context ?".
>
>
> 2008/5/28 Michael McCallum <gh...@apache.org>:
>> I concur with John,
>>
>> The key problem with plugable conflict resolution is that in my case I use
>> hundreds of open source artifacts that all have interdepdencies that work
>> based on the current maven conflict resolution model...
>>
>> If you make it pluggable where do you start and end with any strategy, how do
>> you get a consistent and understandable resolution.
>>
>> One "good" library to bring up would be commons-logging, it ubiquitous many
>> things depend on it. I exclude it because I prefer to use slf4j. If libraries
>> I use have there own strategy could they then override my exclusion or force
>> the tree to resolve such that my exclusions are in the wrong place.
>>
>> To me its like saying people should drive on any side of the road, depending
>> on whats best for them. We don't do that we all drive on the same side of the
>> road in any given country so that we can use the road "safely" with other
>> users in a consistent manner.
>>
>>>> 2008/5/28 John Williams <jr...@pobox.com>:
>>>>> Brett,
>>>>>
>>>>> I'd be happy to work on implementing it, but I'm wary of the idea of
>>>>> pluggable strategies for something as fundamental as version conflict
>>>>> resolution. I agree that any new behavior needs to be switched on
>>>>> with a flag in the pom file in order to avoid breaking legacy builds,
>>>>> but beyond that I don't see much value in letting the user select a
>>>>> strategy. When is an alternate strategy appropriate, and how is a
>>>>> user supposed to make that decision? The sad fact is that pom files
>>>>> don't provide enough information to reliably resolve conflicting
>>>>> versions or detect when no resolution is possible. Any strategy is
>>>>> just a heuristic that will be wrong in some cases, so IMHO it's better
>>>>> to have a single strategy that's easy to understand and override when
>>>>> necessary than to have multiple strategies that all fail in different
>>>>> ways.
>>>>>
>>>>> jw
>>>>>
>>>>> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
>>
>> --
>> Michael McCallum
>> Enterprise Engineer
>> mailto:gholam@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: dependency version conflict resolution
Posted by Gilles Scokart <gs...@gmail.com>.
For the record, note that I didn't argue that maven should do the same
than ivy. Ivy has a general philosophy of flexibility. Maven has a
philosophy of promoting good practices.
I guess that both should be consistent with their general pholosophy...
But I didn't answered to the question "Is it a good practice to adapt
your conflict manager in function of your context ?".
2008/5/28 Michael McCallum <gh...@apache.org>:
> I concur with John,
>
> The key problem with plugable conflict resolution is that in my case I use
> hundreds of open source artifacts that all have interdepdencies that work
> based on the current maven conflict resolution model...
>
> If you make it pluggable where do you start and end with any strategy, how do
> you get a consistent and understandable resolution.
>
> One "good" library to bring up would be commons-logging, it ubiquitous many
> things depend on it. I exclude it because I prefer to use slf4j. If libraries
> I use have there own strategy could they then override my exclusion or force
> the tree to resolve such that my exclusions are in the wrong place.
>
> To me its like saying people should drive on any side of the road, depending
> on whats best for them. We don't do that we all drive on the same side of the
> road in any given country so that we can use the road "safely" with other
> users in a consistent manner.
>
>> > 2008/5/28 John Williams <jr...@pobox.com>:
>> >> Brett,
>> >>
>> >> I'd be happy to work on implementing it, but I'm wary of the idea of
>> >> pluggable strategies for something as fundamental as version conflict
>> >> resolution. I agree that any new behavior needs to be switched on
>> >> with a flag in the pom file in order to avoid breaking legacy builds,
>> >> but beyond that I don't see much value in letting the user select a
>> >> strategy. When is an alternate strategy appropriate, and how is a
>> >> user supposed to make that decision? The sad fact is that pom files
>> >> don't provide enough information to reliably resolve conflicting
>> >> versions or detect when no resolution is possible. Any strategy is
>> >> just a heuristic that will be wrong in some cases, so IMHO it's better
>> >> to have a single strategy that's easy to understand and override when
>> >> necessary than to have multiple strategies that all fail in different
>> >> ways.
>> >>
>> >> jw
>> >>
>> >> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependency version conflict resolution
Posted by Jason van Zyl <ja...@maven.org>.
On 28-May-08, at 8:58 AM, John Williams wrote:
> Sorry about the tangent, but has any work been done yet for
> graph-based dependency resolution?
Yes, the first iteration of it has been in the maven-artifact trunk
for quite some time. Oleg Gusakov worked on the first iteration.
This has spawned two addition strains of work as we progressed and
those are now in the sandbox as mercury. The focus of which is:
- atomic and efficient http transport which will easily support DAV
client connections with robust support for SSL and proxies
- graph based resolution with many corrections for ranges which dove
tails in to the
- incorporation of a SAT solver to deal with the difficult
satisfaction problems of finding a working solution given the use of
ranges
Oleg and I will talk more about it as we progress this week. But we
have variations like scopes, profiles, and conflict resolution where
the processing order makes a huge difference and so we're trying to
arrive at a real spec for how this is done as a part of what we're
doing.
> If I find the time to work on
> Maven that's the first thing I'd want to work on. Aside from being
> able to implement conflict resolution strategies more easily, I think
> a graph-based approach could have other benefits as well. I've looked
> into upgrading Maven's dependency reports to be more like Ivy's (which
> are *vastly* better, IMHO), but Maven's dependency resolution doesn't
> seem to gather enough information to do what I want. In particular,
> Ivy's reports show every path in the dependency graph to each
> artifact, but Maven only shows a single path, and IIRC the dependency
> resolution algorithm uses pruning that would make it impossible to
> discover all paths.
>
> On a related note, Maven's dependency resolution seems to be quite a
> bit faster than than Ivy's, and I suspect Maven's conflict resolution
> heuristic has a lot to do with that because it allows so much pruning
> in the search for dependencies. I suspect any change in conflict
> resolution will make dependency resolution slower, possibly *much*
> slower. Does anyone have a concrete idea of how much speed is gained
> by Maven's aggressive pruning?
>
> On Wed, May 28, 2008 at 9:45 AM, Mark Hobson <ma...@gmail.com>
> wrote:
>> Ideally conflict resolvers would be local to a project, so that they
>> wouldn't have an impact on transitive dependencies. This would be
>> something for the maven-artifact graph-based rewrite, I certainly
>> wouldn't like to patch the current event-based version to achieve
>> this!
>>
>> Mark
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependency version conflict resolution
Posted by John Williams <jr...@pobox.com>.
Sorry about the tangent, but has any work been done yet for
graph-based dependency resolution? If I find the time to work on
Maven that's the first thing I'd want to work on. Aside from being
able to implement conflict resolution strategies more easily, I think
a graph-based approach could have other benefits as well. I've looked
into upgrading Maven's dependency reports to be more like Ivy's (which
are *vastly* better, IMHO), but Maven's dependency resolution doesn't
seem to gather enough information to do what I want. In particular,
Ivy's reports show every path in the dependency graph to each
artifact, but Maven only shows a single path, and IIRC the dependency
resolution algorithm uses pruning that would make it impossible to
discover all paths.
On a related note, Maven's dependency resolution seems to be quite a
bit faster than than Ivy's, and I suspect Maven's conflict resolution
heuristic has a lot to do with that because it allows so much pruning
in the search for dependencies. I suspect any change in conflict
resolution will make dependency resolution slower, possibly *much*
slower. Does anyone have a concrete idea of how much speed is gained
by Maven's aggressive pruning?
On Wed, May 28, 2008 at 9:45 AM, Mark Hobson <ma...@gmail.com> wrote:
> Ideally conflict resolvers would be local to a project, so that they
> wouldn't have an impact on transitive dependencies. This would be
> something for the maven-artifact graph-based rewrite, I certainly
> wouldn't like to patch the current event-based version to achieve
> this!
>
> Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependency version conflict resolution
Posted by Mark Hobson <ma...@gmail.com>.
I meant that if your project declared a different conflict resolver,
then it wouldn't necessarily be used when resolving its dependencies'
conflicts.
For example, if Hibernate's pom declared nearest-wins, but your
project that depended upon Hibernate declared highest-wins, then
nearest-wins would be used to resolve Hibernate's subgraph, the result
of which would then be fed into your project's graph for highest-wins
resolution. I haven't totally thought this through, but a localised
approach to different conflict resolvers would be my gut reaction.
Mark
2008/5/28 Brian E. Fox <br...@reply.infinity.nu>:
> How can it not affect transitive dependencies? It is in fact the
> transitives that cause the conflicts in the first place.
>
> -----Original Message-----
> From: Mark Hobson [mailto:markhobson@gmail.com]
> Sent: Wednesday, May 28, 2008 10:45 AM
> To: Maven Developers List
> Subject: Re: dependency version conflict resolution
>
> Ideally conflict resolvers would be local to a project, so that they
> wouldn't have an impact on transitive dependencies. This would be
> something for the maven-artifact graph-based rewrite, I certainly
> wouldn't like to patch the current event-based version to achieve
> this!
>
> Mark
>
> 2008/5/28 Brian E. Fox <br...@reply.infinity.nu>:
>> My concern is the same, but I'll take it a step further. Custom
> conflict
>> resolution strategies reduce the overall ability to jump in and
>> understand any Maven build.
>>
>> -----Original Message-----
>> From: Michael McCallum [mailto:gholam@apache.org]
>> Sent: Wednesday, May 28, 2008 9:45 AM
>> To: Maven Developers List
>> Subject: Re: dependency version conflict resolution
>>
>> I concur with John,
>>
>> The key problem with plugable conflict resolution is that in my case I
>> use
>> hundreds of open source artifacts that all have interdepdencies that
>> work
>> based on the current maven conflict resolution model...
>>
>> If you make it pluggable where do you start and end with any strategy,
>> how do
>> you get a consistent and understandable resolution.
>>
>> One "good" library to bring up would be commons-logging, it ubiquitous
>> many
>> things depend on it. I exclude it because I prefer to use slf4j. If
>> libraries
>> I use have there own strategy could they then override my exclusion or
>> force
>> the tree to resolve such that my exclusions are in the wrong place.
>>
>> To me its like saying people should drive on any side of the road,
>> depending
>> on whats best for them. We don't do that we all drive on the same side
>> of the
>> road in any given country so that we can use the road "safely" with
>> other
>> users in a consistent manner.
>>
>>> > 2008/5/28 John Williams <jr...@pobox.com>:
>>> >> Brett,
>>> >>
>>> >> I'd be happy to work on implementing it, but I'm wary of the idea
>> of
>>> >> pluggable strategies for something as fundamental as version
>> conflict
>>> >> resolution. I agree that any new behavior needs to be switched on
>>> >> with a flag in the pom file in order to avoid breaking legacy
>> builds,
>>> >> but beyond that I don't see much value in letting the user select
> a
>>> >> strategy. When is an alternate strategy appropriate, and how is a
>>> >> user supposed to make that decision? The sad fact is that pom
>> files
>>> >> don't provide enough information to reliably resolve conflicting
>>> >> versions or detect when no resolution is possible. Any strategy
> is
>>> >> just a heuristic that will be wrong in some cases, so IMHO it's
>> better
>>> >> to have a single strategy that's easy to understand and override
>> when
>>> >> necessary than to have multiple strategies that all fail in
>> different
>>> >> ways.
>>> >>
>>> >> jw
>>> >>
>>> >> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org>
>> wrote:
>>
>>
>> --
>> Michael McCallum
>> Enterprise Engineer
>> mailto:gholam@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
>>
>>
>
> ---------------------------------------------------------------------
> 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: dependency version conflict resolution
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
How can it not affect transitive dependencies? It is in fact the
transitives that cause the conflicts in the first place.
-----Original Message-----
From: Mark Hobson [mailto:markhobson@gmail.com]
Sent: Wednesday, May 28, 2008 10:45 AM
To: Maven Developers List
Subject: Re: dependency version conflict resolution
Ideally conflict resolvers would be local to a project, so that they
wouldn't have an impact on transitive dependencies. This would be
something for the maven-artifact graph-based rewrite, I certainly
wouldn't like to patch the current event-based version to achieve
this!
Mark
2008/5/28 Brian E. Fox <br...@reply.infinity.nu>:
> My concern is the same, but I'll take it a step further. Custom
conflict
> resolution strategies reduce the overall ability to jump in and
> understand any Maven build.
>
> -----Original Message-----
> From: Michael McCallum [mailto:gholam@apache.org]
> Sent: Wednesday, May 28, 2008 9:45 AM
> To: Maven Developers List
> Subject: Re: dependency version conflict resolution
>
> I concur with John,
>
> The key problem with plugable conflict resolution is that in my case I
> use
> hundreds of open source artifacts that all have interdepdencies that
> work
> based on the current maven conflict resolution model...
>
> If you make it pluggable where do you start and end with any strategy,
> how do
> you get a consistent and understandable resolution.
>
> One "good" library to bring up would be commons-logging, it ubiquitous
> many
> things depend on it. I exclude it because I prefer to use slf4j. If
> libraries
> I use have there own strategy could they then override my exclusion or
> force
> the tree to resolve such that my exclusions are in the wrong place.
>
> To me its like saying people should drive on any side of the road,
> depending
> on whats best for them. We don't do that we all drive on the same side
> of the
> road in any given country so that we can use the road "safely" with
> other
> users in a consistent manner.
>
>> > 2008/5/28 John Williams <jr...@pobox.com>:
>> >> Brett,
>> >>
>> >> I'd be happy to work on implementing it, but I'm wary of the idea
> of
>> >> pluggable strategies for something as fundamental as version
> conflict
>> >> resolution. I agree that any new behavior needs to be switched on
>> >> with a flag in the pom file in order to avoid breaking legacy
> builds,
>> >> but beyond that I don't see much value in letting the user select
a
>> >> strategy. When is an alternate strategy appropriate, and how is a
>> >> user supposed to make that decision? The sad fact is that pom
> files
>> >> don't provide enough information to reliably resolve conflicting
>> >> versions or detect when no resolution is possible. Any strategy
is
>> >> just a heuristic that will be wrong in some cases, so IMHO it's
> better
>> >> to have a single strategy that's easy to understand and override
> when
>> >> necessary than to have multiple strategies that all fail in
> different
>> >> ways.
>> >>
>> >> jw
>> >>
>> >> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org>
> wrote:
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@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
>
>
---------------------------------------------------------------------
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: dependency version conflict resolution
Posted by Mark Hobson <ma...@gmail.com>.
Ideally conflict resolvers would be local to a project, so that they
wouldn't have an impact on transitive dependencies. This would be
something for the maven-artifact graph-based rewrite, I certainly
wouldn't like to patch the current event-based version to achieve
this!
Mark
2008/5/28 Brian E. Fox <br...@reply.infinity.nu>:
> My concern is the same, but I'll take it a step further. Custom conflict
> resolution strategies reduce the overall ability to jump in and
> understand any Maven build.
>
> -----Original Message-----
> From: Michael McCallum [mailto:gholam@apache.org]
> Sent: Wednesday, May 28, 2008 9:45 AM
> To: Maven Developers List
> Subject: Re: dependency version conflict resolution
>
> I concur with John,
>
> The key problem with plugable conflict resolution is that in my case I
> use
> hundreds of open source artifacts that all have interdepdencies that
> work
> based on the current maven conflict resolution model...
>
> If you make it pluggable where do you start and end with any strategy,
> how do
> you get a consistent and understandable resolution.
>
> One "good" library to bring up would be commons-logging, it ubiquitous
> many
> things depend on it. I exclude it because I prefer to use slf4j. If
> libraries
> I use have there own strategy could they then override my exclusion or
> force
> the tree to resolve such that my exclusions are in the wrong place.
>
> To me its like saying people should drive on any side of the road,
> depending
> on whats best for them. We don't do that we all drive on the same side
> of the
> road in any given country so that we can use the road "safely" with
> other
> users in a consistent manner.
>
>> > 2008/5/28 John Williams <jr...@pobox.com>:
>> >> Brett,
>> >>
>> >> I'd be happy to work on implementing it, but I'm wary of the idea
> of
>> >> pluggable strategies for something as fundamental as version
> conflict
>> >> resolution. I agree that any new behavior needs to be switched on
>> >> with a flag in the pom file in order to avoid breaking legacy
> builds,
>> >> but beyond that I don't see much value in letting the user select a
>> >> strategy. When is an alternate strategy appropriate, and how is a
>> >> user supposed to make that decision? The sad fact is that pom
> files
>> >> don't provide enough information to reliably resolve conflicting
>> >> versions or detect when no resolution is possible. Any strategy is
>> >> just a heuristic that will be wrong in some cases, so IMHO it's
> better
>> >> to have a single strategy that's easy to understand and override
> when
>> >> necessary than to have multiple strategies that all fail in
> different
>> >> ways.
>> >>
>> >> jw
>> >>
>> >> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org>
> wrote:
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: dependency version conflict resolution
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
My concern is the same, but I'll take it a step further. Custom conflict
resolution strategies reduce the overall ability to jump in and
understand any Maven build.
-----Original Message-----
From: Michael McCallum [mailto:gholam@apache.org]
Sent: Wednesday, May 28, 2008 9:45 AM
To: Maven Developers List
Subject: Re: dependency version conflict resolution
I concur with John,
The key problem with plugable conflict resolution is that in my case I
use
hundreds of open source artifacts that all have interdepdencies that
work
based on the current maven conflict resolution model...
If you make it pluggable where do you start and end with any strategy,
how do
you get a consistent and understandable resolution.
One "good" library to bring up would be commons-logging, it ubiquitous
many
things depend on it. I exclude it because I prefer to use slf4j. If
libraries
I use have there own strategy could they then override my exclusion or
force
the tree to resolve such that my exclusions are in the wrong place.
To me its like saying people should drive on any side of the road,
depending
on whats best for them. We don't do that we all drive on the same side
of the
road in any given country so that we can use the road "safely" with
other
users in a consistent manner.
> > 2008/5/28 John Williams <jr...@pobox.com>:
> >> Brett,
> >>
> >> I'd be happy to work on implementing it, but I'm wary of the idea
of
> >> pluggable strategies for something as fundamental as version
conflict
> >> resolution. I agree that any new behavior needs to be switched on
> >> with a flag in the pom file in order to avoid breaking legacy
builds,
> >> but beyond that I don't see much value in letting the user select a
> >> strategy. When is an alternate strategy appropriate, and how is a
> >> user supposed to make that decision? The sad fact is that pom
files
> >> don't provide enough information to reliably resolve conflicting
> >> versions or detect when no resolution is possible. Any strategy is
> >> just a heuristic that will be wrong in some cases, so IMHO it's
better
> >> to have a single strategy that's easy to understand and override
when
> >> necessary than to have multiple strategies that all fail in
different
> >> ways.
> >>
> >> jw
> >>
> >> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org>
wrote:
--
Michael McCallum
Enterprise Engineer
mailto:gholam@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: dependency version conflict resolution
Posted by Michael McCallum <gh...@apache.org>.
I concur with John,
The key problem with plugable conflict resolution is that in my case I use
hundreds of open source artifacts that all have interdepdencies that work
based on the current maven conflict resolution model...
If you make it pluggable where do you start and end with any strategy, how do
you get a consistent and understandable resolution.
One "good" library to bring up would be commons-logging, it ubiquitous many
things depend on it. I exclude it because I prefer to use slf4j. If libraries
I use have there own strategy could they then override my exclusion or force
the tree to resolve such that my exclusions are in the wrong place.
To me its like saying people should drive on any side of the road, depending
on whats best for them. We don't do that we all drive on the same side of the
road in any given country so that we can use the road "safely" with other
users in a consistent manner.
> > 2008/5/28 John Williams <jr...@pobox.com>:
> >> Brett,
> >>
> >> I'd be happy to work on implementing it, but I'm wary of the idea of
> >> pluggable strategies for something as fundamental as version conflict
> >> resolution. I agree that any new behavior needs to be switched on
> >> with a flag in the pom file in order to avoid breaking legacy builds,
> >> but beyond that I don't see much value in letting the user select a
> >> strategy. When is an alternate strategy appropriate, and how is a
> >> user supposed to make that decision? The sad fact is that pom files
> >> don't provide enough information to reliably resolve conflicting
> >> versions or detect when no resolution is possible. Any strategy is
> >> just a heuristic that will be wrong in some cases, so IMHO it's better
> >> to have a single strategy that's easy to understand and override when
> >> necessary than to have multiple strategies that all fail in different
> >> ways.
> >>
> >> jw
> >>
> >> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependency version conflict resolution
Posted by Paul Gier <pg...@redhat.com>.
Not much to add other than "I agree". I think maven should take an approach
similar to Ivy. Allow users to choose from some common conflict resolution
strategies, or implement their own if none of the standard ones meet their needs.
Gilles Scokart wrote:
> There are actually plenty of conflict resolution strategy. Every
> users may preffer its own style based on the characteristics of its
> project, depending on what level of control he want to have versus the
> effort he want to give, depending of the size of its project,
> depending on the typical release cycle used in its organisation, etc.
>
> Some people consider a conflict is not acceptable, and should broke
> the build. Other want some very clear warning that can be manually
> checked when conflict is detected and resolved, others doesn't care
> and just rely on the test to check everything is ok.
>
> In Ivy, we are giving the possibility to plug different conflict
> managers [1]. In ivy, that fit with the overall philosiphy that we
> want to give the maximum flexibility to the user.
>
>
> [1] http://ant.apache.org/ivy/history/latest-milestone/configuration/conflict-managers.html
>
> 2008/5/28 John Williams <jr...@pobox.com>:
>> Brett,
>>
>> I'd be happy to work on implementing it, but I'm wary of the idea of
>> pluggable strategies for something as fundamental as version conflict
>> resolution. I agree that any new behavior needs to be switched on
>> with a flag in the pom file in order to avoid breaking legacy builds,
>> but beyond that I don't see much value in letting the user select a
>> strategy. When is an alternate strategy appropriate, and how is a
>> user supposed to make that decision? The sad fact is that pom files
>> don't provide enough information to reliably resolve conflicting
>> versions or detect when no resolution is possible. Any strategy is
>> just a heuristic that will be wrong in some cases, so IMHO it's better
>> to have a single strategy that's easy to understand and override when
>> necessary than to have multiple strategies that all fail in different
>> ways.
>>
>> jw
>>
>> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
>>> 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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependency version conflict resolution
Posted by Gilles Scokart <gs...@gmail.com>.
There are actually plenty of conflict resolution strategy. Every
users may preffer its own style based on the characteristics of its
project, depending on what level of control he want to have versus the
effort he want to give, depending of the size of its project,
depending on the typical release cycle used in its organisation, etc.
Some people consider a conflict is not acceptable, and should broke
the build. Other want some very clear warning that can be manually
checked when conflict is detected and resolved, others doesn't care
and just rely on the test to check everything is ok.
In Ivy, we are giving the possibility to plug different conflict
managers [1]. In ivy, that fit with the overall philosiphy that we
want to give the maximum flexibility to the user.
[1] http://ant.apache.org/ivy/history/latest-milestone/configuration/conflict-managers.html
2008/5/28 John Williams <jr...@pobox.com>:
> Brett,
>
> I'd be happy to work on implementing it, but I'm wary of the idea of
> pluggable strategies for something as fundamental as version conflict
> resolution. I agree that any new behavior needs to be switched on
> with a flag in the pom file in order to avoid breaking legacy builds,
> but beyond that I don't see much value in letting the user select a
> strategy. When is an alternate strategy appropriate, and how is a
> user supposed to make that decision? The sad fact is that pom files
> don't provide enough information to reliably resolve conflicting
> versions or detect when no resolution is possible. Any strategy is
> just a heuristic that will be wrong in some cases, so IMHO it's better
> to have a single strategy that's easy to understand and override when
> necessary than to have multiple strategies that all fail in different
> ways.
>
> jw
>
> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
>> 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
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependency version conflict resolution
Posted by John Williams <jr...@pobox.com>.
Brett,
I'd be happy to work on implementing it, but I'm wary of the idea of
pluggable strategies for something as fundamental as version conflict
resolution. I agree that any new behavior needs to be switched on
with a flag in the pom file in order to avoid breaking legacy builds,
but beyond that I don't see much value in letting the user select a
strategy. When is an alternate strategy appropriate, and how is a
user supposed to make that decision? The sad fact is that pom files
don't provide enough information to reliably resolve conflicting
versions or detect when no resolution is possible. Any strategy is
just a heuristic that will be wrong in some cases, so IMHO it's better
to have a single strategy that's easy to understand and override when
necessary than to have multiple strategies that all fail in different
ways.
jw
On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
> 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
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
Pom changes in 2.1 (was Re: dependency version conflict resolution)
Posted by Paul Gier <pg...@redhat.com>.
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: dependency version conflict resolution
Posted by Mark Hobson <ma...@gmail.com>.
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
Re: dependency version conflict resolution
Posted by 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
RE: dependency version conflict resolution
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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
Re: dependency version conflict resolution
Posted by Brett Porter <br...@apache.org>.
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