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. -ketan Gilles Scokart <[EMAIL PROTECTED]> wrote: It looks like something that has been discussed there: http://www.nabble.com/Dealing-with-deleted-revisions-tf3149671.html Is your concern similar? Gilles > -----Original Message----- > From: Ketan Lamba [mailto:[EMAIL PROTECTED] > Sent: mardi 20 février 2007 23:50 > To: [email protected] > 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.
