Re: Pluggable Dependency Resolution

2011-07-31 Thread Ralph Goers
some > method parameter or config tag expresses version and capability... > > LieGrue, > strub > > PS: you can at least check the backward compat of your own lib with the > maven-clirr-plugin. > > --- On Sun, 7/31/11, Jason van Zyl wrote: > >> From: Ja

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Derricutt
I've been meaning to check out the clirr-plugin - I'll add that to my TODO reading list for the morning. On 1/08/2011, at 12:15 AM, Mark Struberg wrote: > PS: you can at least check the backward compat of your own lib with the > maven-clirr-plugin.

Re: Pluggable Dependency Resolution

2011-07-31 Thread Stuart McCulloch
On Sun, 7/31/11, Jason van Zyl wrote: > >> From: Jason van Zyl >> Subject: Re: Pluggable Dependency Resolution >> To: "Maven Developers List" >> Date: Sunday, July 31, 2011, 11:58 AM >> What if you could find another way to >> check API compatibil

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Derricutt
Potentially not. I suppose if there was a way to say [2.0.0,3.0.0) *excluding SNAPSHOTS* then that would certainly be in my favor. From memory there was a discussion some time ago regarding range resolution excluding -SNAPSHOTs unless the artifacts were also in the current reactor build, from

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Struberg
/11, Jason van Zyl wrote: > From: Jason van Zyl > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" > Date: Sunday, July 31, 2011, 11:58 AM > What if you could find another way to > check API compatibility, would you need this at all? > >

Re: Pluggable Dependency Resolution

2011-07-31 Thread Jason van Zyl
What if you could find another way to check API compatibility, would you need this at all? On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: > The use case that we originally came with in our discussions revolved around > version ranges, and the fact that a version reference of "2.5.4" doesn't

Re: Pluggable Dependency Resolution

2011-07-31 Thread Jason van Zyl
On Jul 31, 2011, at 3:27 AM, Stephen Connolly wrote: > i see two concerns that need separation. > > 1. the code that fetches dependencies from wherever they live. > Sure, I've known people to change this in many ways. Integration of legacy artifact stores, migration strategies which involve p

Re: Pluggable Dependency Resolution

2011-07-31 Thread Stephen Connolly
ok, in the past i have had discussions with Jason over version range syntax. Jason previously expoused the view that osgi format version numbers is the -only- way to have version numbers, and anything else he would not support. at the time i was working for a company where we had 5 segment version

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Derricutt
Not from any of my use cases no. Mark On 31/07/2011, at 10:18 PM, Hervé BOUTEMY wrote: > This lets the question of pluggable version comparison need: is there a real > world example of unwanted version order?

Re: Pluggable Dependency Resolution

2011-07-31 Thread Hervé BOUTEMY
Le dimanche 31 juillet 2011, Mark Derricutt a écrit : > The use case that we originally came with in our discussions revolved > around version ranges, ok, that's not a version comparison but version (range) resolution question: version ordering is here to define how artifacts are ordered, then the

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Derricutt
The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of "2.5.4" doesn't actually mean " give me 2.5.4" but rather "I would like 2.5.4, but meh, use something higher if you need to". In the case were you have artifacts

Re: Pluggable Dependency Resolution

2011-07-31 Thread Hervé BOUTEMY
I see this one regularly and don't frankly understand the need other than pure theory. Actual version comparison supports every numbering scheme I ever saw in reality. The only choice that has been made that is a pure choice (neither good nor bad, just a choice had to be made) is that unknown qu

Re: Pluggable Dependency Resolution

2011-07-31 Thread Hervé BOUTEMY
t; > From: Igor Fedorenko > > Subject: Re: Pluggable Dependency Resolution > > To: dev@maven.apache.org > > Date: Sunday, July 31, 2011, 7:51 AM > > It is sort-of possible to plug > > per-project dependency resolver and this > > is more or less how Tycho w

Re: Pluggable Dependency Resolution

2011-07-31 Thread Igor Fedorenko
this could be done in settings.xml! LieGrue, strub --- On Sun, 7/31/11, Igor Fedorenko wrote: From: Igor Fedorenko Subject: Re: Pluggable Dependency Resolution To: dev@maven.apache.org Date: Sunday, July 31, 2011, 7:51 AM It is sort-of possible to plug per-project dependency resolver and this is mo

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Struberg
om: Igor Fedorenko > Subject: Re: Pluggable Dependency Resolution > To: dev@maven.apache.org > Date: Sunday, July 31, 2011, 7:51 AM > It is sort-of possible to plug > per-project dependency resolver and this > is more or less how Tycho works already (I can provide more > detai

Re: Pluggable Dependency Resolution

2011-07-31 Thread Mark Struberg
a few times and you see what I mean. After max 10 upgrades, your Eclipse installation is completely messed up as you _will_ get conflicting dependencies which don't work together nicely. --- On Sun, 7/31/11, Stephen Connolly wrote: > From: Stephen Connolly > Subject: Re: Plug

Re: Pluggable Dependency Resolution

2011-07-31 Thread Igor Fedorenko
to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. With the rise of these ASF/EPL threads I again thought of the pluggable

Re: Pluggable Dependency Resolution

2011-07-31 Thread Stephen Connolly
oh i forgot to mention. i also think that version comparison rules should be plugable. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 08:27, "Stephen Connolly"

Re: Pluggable Dependency Resolution

2011-07-31 Thread Stephen Connolly
i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. 2. the code that computed the dependencies graph. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way

Re: Pluggable Dependency Resolution

2011-07-30 Thread Mark Struberg
Zyl > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" > Date: Saturday, July 30, 2011, 11:58 PM > On Jul 30, 2011, at 7:14 PM, Mark > Derricutt wrote: > > > Hi all, > > > > I wanted to start this discussion completely separate

Re: Pluggable Dependency Resolution

2011-07-30 Thread Jason van Zyl
egal Argument podcast ) have often > discussed a desire to have a pluggable dependency resolution mechanism within > Apache Maven, mostly around having the ability to force maven to use the > lowest bound in a range rather than the highest for highlight fast-fail API > breakag

Re: Pluggable Dependency Resolution

2011-07-30 Thread Mark Derricutt
On 31/07/2011, at 11:14 AM, Mark Derricutt wrote: > I imagine a difficulty in that this would have to occur early in the > bootstrap process of maven, but if this were the case, would we not be able > to work a solution to not only the Aether inclusion issues, but also Kasun's > Gentoo resolut

Pluggable Dependency Resolution

2011-07-30 Thread Mark Derricutt
Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency