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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> wrote:
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
