Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of xavier.hanin@gmail.com
 designates 209.85.146.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=dyHymMlQhf7AxhzKshYDmqiyQ/nd3/WPOvcukuEmGUtHgM49yw/TNlVt97NuOk+o7lfZibI3d33MhCZrqs4+v5C8QUBHZYrn+XgGRa+RBdGj0eRjGCnVt+tNSGbPPrPJVE4wLVbfMFmTZdYCKm5c0xh7VSlvFM02wesR9od/35k=
Message-ID: <635a05060706120539n3ab8f3ddg2f7406596e95155@mail.gmail.com>
Date: Tue, 12 Jun 2007 14:39:34 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Working with version ranges
In-Reply-To: <05e601c7aced$002686e0$2120a8c0@isabelteam.be>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4550_7850445.1181651974917"
References: <05e601c7aced$002686e0$2120a8c0@isabelteam.be>

------=_Part_4550_7850445.1181651974917
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/12/07, Gilles Scokart <gscokart@gmail.com> wrote:
>
>
>
> The current ivy implementation can use version ranges in its dependency.
> When using a range ivy search for the latest revision available in the
> repository that will match the range.  (Correct me if I'm wrong!).


Indeed, this is how Ivy works.

Shouldn't ivy take into account the other dependencies as well?  For
> example, if we have A depending on C version [1.0,3.0[, and A depending B
> which depends on V version 1.5.
> The current implementation will return the latest available revision
> contained in [1.0,3.0[.  Shouldn't ivy return the revision 1.5, even if
> there are 2.1 in the repository?  (If it is already possible to do that,
> tell me how).


It's something that could be useful, and that we "need" to implement to be
compatible with maven 2 version ranges processing. This requires some
thought, because this is something that is even more useful in published
metadata. Some users have already requested something like storing two
information in the published metadata: the compatible range and the exact
version to which the dependency resolution lead at time of publication (the
only information available right now). This could be useful for conflict
management too, to tell if a dependency is resolved outside the compatiblity
scope (which is also something that maven 2 does).

Also, I'm wondering if it wouldn't make sense to take the first available
> version.  Indeed if I say that my modules requires 1.+, I think it's
> better
> to compile with a 1.0 version.  Indeed, the probability is bigger that a
> version compiled/tested with 1.0 works also with a 1.1 than the opposite
> (a
> version compiled/tested with 1.1 working with a 1.0).  Also when we
> publish,
> if we want to fix the published dependencies, I'm wondering if it wouldn't
> not be better to publish 1.0, instead of 1.x (where x is the highest
> number
> available when we make the build).


Maybe this is something that need to be more flexible than it is. Version
mediation is not an easy thing, but we could try to have something flexible
enough to handle both cases (take the latest or oldest possible which is not
conflicting with another one). What makes this kind of thing difficult is
that we do not have access to the whole dependency graph: we need to
download metadata to acquire information about modules, and this is a costly
operation that Ivy tries to do as few times as possible. But improving this
kind of flexibility would definitely be helpful if well thought.

Xavier

WDYT?
>
> Gilles
>
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

------=_Part_4550_7850445.1181651974917--