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
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 spawn
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 o
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
n strategies reduce the overall ability to jump in and
>> understand any Maven build.
>>
>> -Original Message-
>> From: Michael McCallum [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, May 28, 2008 9:45 AM
>> To: Maven Developers List
>> Subject: Re:
Callum [mailto:[EMAIL PROTECTED]
> 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
lto:[EMAIL PROTECTED]
> 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
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...
I
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
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
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
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
>> 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 c
ay 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 does
nal Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 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 -
howeve
ednesday, 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 b
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
I thought Mark already started this and/or has a proposal on the wiki.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 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
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 contribut
19 matches
Mail list logo
