ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Korobskiy <dkro...@gmail.com>
Subject Re: Resolving Dependencies not to patch level
Date Tue, 18 Sep 2007 20:46:03 GMT
Exactly. I think that saying "your builds are not reproducible
if you don't explicitly state what revision you build against." is 
technically correct, but it might lead a reader to think that if you 
have dynamic revisions in Ivy, you'd automatically have non-reproducible 
builds. I'm not sure, John, if you meant that or not, but it's important 
  to clarify.

While you might have dynamic revisions in "source" Ivy file, delivered 
Ivy files get all revisions fixed at the point of <ivy:deliver/>. See 
these points, for example, in the Mathias' doc:

"# Deliver the ivy file with appropriate status (currently always 
"release", since we don't use milestone and integration builds yet, as 
noted above).
# Publish the delivered ivy file and the artifacts."

Hence, if you build system is written correctly, you'd use SCM 
labeling/branching on your repositories (assuming you have repositories 
under SCM, and not using public repositories) or "delivered" Ivy files 
to reproduce the builds.

So, to have reproducible builds, you need to have SCM and build system 
set up correctly.

Xavier Hanin wrote:
> 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
>>
> 
> 
> 

-- 
DK <1-127-441 @ICQ, DKroot @Skype>
<DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk or @MSN, dk_root 
@Yahoo>

Mime
View raw message