ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ketan Lamba <>
Subject RE: Request for feature
Date Wed, 21 Feb 2007 19:46:31 GMT
It is similar in some sense. But there seems to be no decision making done in that case.
For example consider case
We are trying to build a module A that depends on B and C version 2.0.
> B depends on: D [1.2, 1.5]
>  C depends on: D [1.1, 1.4]
The repository has D versions 1.0, 1.1, 1.2, 1.3, 1.5, 1.6

When B 2.0 was built and published D rev 1.5 was used based on latest revision strategy.

When C 2.0 was built and published D rev 1.3 was used.

But when we are building A we would end up using 1.5 over 1.3 rev of D. This is erroneous
because C does not   support 1.5.
If there was a way for us to have original range info also available in repository ivy.xmls
of B and C we could write a conflict manager and resolver that would take the "greatest common"
available version, which in this case would be 1.3

I gave bad example in previous post.
Gilles Scokart <> wrote: It looks like something that has been discussed

Is your concern similar?  


> -----Original Message-----
> From: Ketan Lamba []
> Sent: mardi 20 février 2007 23:50
> To:
> Subject: Request for feature
> Hi,
> We have been using ivy-1.4.1 and noticed that there is need for important
> descriptor to be added to ivy.xml files that are published to repository.
> Since we can use ranges with 1.4 it would be important to add a descriptor
> that specifies the original ranges for dependencies in the resolved
> ivy.xml. This should be addedto ivy.xml for the module when its published
> to repository.
> This would enable decision making like selecting "greatest common version"
> of a dependency.
> for example :
> We are trying to build a module A that depends on B and C.
> B depends on: D [1.0, 2.0[
>  C depends on: D [1.2, 1.6[
>   Module B asks for any 1.N build of module D while C asks only for the
> latest  revision of module D's from 1.2 up to 1.5 release.
>   Result: Build succeeds, and includes greatest "common" version of module
> D that satisfies the constraints by both B and C. We notify the builder in
> a summarized Ivy report if there is a newer version than 1.5 that we are
> prevented
> from including here due to C's dependency.
> Currently: When module A is being built and dependencies for B and C are
> resolved the ivy.xmls from repository only provide 1.N version of D that
> was used by B and C versions requested by A.
> thanks
> -ketan
> ---------------------------------
> Don't be flakey. Get Yahoo! Mail for Mobile and
> always stay connected to friends.

Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message