On 9/18/07, Nascif Abousalh-Neto <[EMAIL PROTECTED]> wrote: > > Hi John, > > You are correct that just storing the ivy.xml file with the ranges (and > I believe any kind of wildcard, like latest.*) will not allow for a > reproducible build. One approach to solve this problem is to retrieve > the resolved ivy.xml file from the repository, add it to source control, > and then applying your label/tag.
There's also Matthias Killian's solution: http://dead-parrot.de/ivy/ Xavier Regards, > Nascif > > -----Original Message----- > From: John Gill [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 18, 2007 5:26 AM > To: [email protected] > Subject: Re: Resolving Dependencies not to patch level > > Even if the symlink idea did ignore the version, the next problem would > be that once you have resolved that version to your cache, if you move > the symlink, ivy probably wont pick what it now points to and will use > the old revision in the cache. > > If you want revision 1.0, then why use ranges at all? Just have the ivy > file of the project that wants revision 1.0 say it wants revision 1.0. > > Actually, I am not sure what the philosophy of this whole revision range > thing is, because doesn't it mean that your builds are not reproducible > if you don't explicitly state what revision you build against. > > For example, lets say we have ProjectX, and we label/tag our code in > SVN/ClearCase/CVS, etc (we all do that right?) to mark release 1.0 of > ProjectX. In the tagged 1.0 ivy.xml for ProductX it has a revision range > for log4j, and then 6 months down the track, we need to rebuild this > version (to fix some bug), and now there are 5 new log4j revisions that > fall into the range. If we build from our tagged ivy.xml file, it could > well end up rebuilding against a completely different log4j library that > it was originally built against. Isn't that bad? > > It seems to me that using version ranges leads to unreproducible builds > (from your tagged source code in the SCM repository), and in order to > use then you must sacrifice that reproducibility. > > On 9/18/07, Foreman, Alex (IT) <[EMAIL PROTECTED]> > wrote: > > > > HI again, Need a bit more help. > > > > I have looked at the dependencies and there Fixed and dynamic > revisions. > > But I cant see a way of resolving my specific problem. > > > > I have a file system holding folders like this: > > > > 1.0 -> 1.0.0 (symlink) > > 1.0.0 > > 1.0.1 > > > > 1.0.0 and 1.0.1 are separate Major minor patch versions of a specific > > project. > > > > Atm the symlink for Major/ Minor 1.0 is pointed to 1.0.0. > > > > I want to use 1.0 as the revision (or possibly even a symlink called > > prod / qa etc) which will go through the symlink to the correct > version. > > Currently doing this we get the error that 'bad revision found in blah > > > blah expected='1.0 found='1.0.0'. > > > > Is there anyway to remove this checking on the revision version? I > > cannot use the built in + o x or even [1.0,) as the latest number > > given might be a non-production release. Eg in the situation above > > ivy would find 1.0.1 but we want to use 1.0.0 which we are symlinked > to. > > > > As these numbers and text symlinks are going to point to version > > numbers they will regurally not be the same as the revision number in > the file. > > > > If this is not possible in Ivy can you tell me what I have to do to > > make this possible as this is a Blocker. > > > > Again many thanks for your help, > > > > Alex > > -------------------------------------------------------- > > > > NOTICE: If received in error, please destroy and notify sender. Sender > > > does not intend to waive confidentiality or privilege. Use of this > > email is prohibited when received in error. > > > > > > -- > Regards, > John Gill > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
