Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of llignhoj@gmail.com designates
 209.85.198.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=GThArfgP/o2MoUbAau/cb/rD3UY0u2jdu11EUcq6vx9ySJynU8ddiufCrKf1PzZKQsqAIgkEEgdWAjrSQI9JuKT8S3O9ppjczL869RX/E9gFz2S+U49BRkXP/CLaYNfhV3p9Do2uuXf556huwmQlgP3Ak/TO/GXmQW0/mzxijuo=
Message-ID: <49c77ae40709180225l15138d9r950bbd8d71c95d52@mail.gmail.com>
Date: Tue, 18 Sep 2007 17:25:46 +0800
From: "John Gill" <llignhoj@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Resolving Dependencies not to patch level
In-Reply-To: <C6F6F223BE7B0F41981E1D24BEE8FFA9102F1D68@LNWEXMB33.msad.ms.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5675_7861103.1190107546538"
References: <C6F6F223BE7B0F41981E1D24BEE8FFA9102F1D68@LNWEXMB33.msad.ms.com>

------=_Part_5675_7861103.1190107546538
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_5675_7861103.1190107546538--