ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Resolving Dependencies not to patch level
Date Tue, 18 Sep 2007 16:07:35 GMT
On 9/18/07, Nascif Abousalh-Neto <Nascif.AbousalhNeto@sas.com> 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:llignhoj@gmail.com]
> Sent: Tuesday, September 18, 2007 5:26 AM
> To: ivy-user@incubator.apache.org
> 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) <Alexander.Foreman@morganstanley.com>
> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message