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
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.
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
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
/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?
>
>
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
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
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
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?
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
23 matches
Mail list logo