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] > > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
