ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Foreman, Alex \(IT\)" <Alexander.Fore...@morganstanley.com>
Subject RE: Resolving Dependencies not to patch level
Date Thu, 20 Sep 2007 15:26:56 GMT
Hi,
This has been a great help.

The symlinks have to be used unfortunatly.  
The properties idea might solve my previous problem of having a one stop
for all dependencies.

So far Ivy has done everything I've asked and Im finding it very
competent and helpful.

I have one problem left in my use case.  I need to be able to add JNI
paths to the classpath.

I have tried:
<artifact name="a_jni_file" type="jni" ext="so"
url="file://path/to/jnidir/a_jni_file.so"/>
But it doesn't seem to resolve.  I also need these to come up in Ivydev.

Is there a nice way of using JNI in this case?

Again,  Your help is much appreciated,

Many thanks,
Alex

-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: 18 September 2007 17:12
To: ivy-user@incubator.apache.org
Subject: Re: Resolving Dependencies not to patch level

You can disable metadata check by Ivy, but as John says it will only
solve a part of the problem. If you want to try this out, you just need
to set checkconsistency="false" on your dependency resolver in your
settings.

BTW, for your use case, what you can do is use a property as metadata.
For example put ${foo.bar.1.0} as revision, then set foo.bar.1.0=1.0.0
or
foo.bar.1.0=1.0.1 in a property file for instance. This will avoid the
whole symlink mechanism, and Ivy will actually know which version you
are using, which is much better IMHO for reporting and build
reproducibility.

HTH,

Xavier

On 9/18/07, Foreman, Alex (IT) <Alexander.Foreman@morganstanley.com>
wrote:
>
> We are currently using useOrigin=true so nothing is downloaded to 
> cache so we will pick up the version through the symlink each time.
> If this is a problem we will automatically clean the cache each time 
> before building, this is not a problem for me.
>
> If people use 1.0 the symlink and it points to 1.0.0 the folder and
> 1.0.1 gets released.  We move the symlink over.  Everyone 
> automatically upgrades to 1.0.1.  If there is a problem with 1.0.1 and

> it breaks peoples code then we can roll the symlink back to 1.0.0 and 
> everything works again.
>
> If people want to point to a certain version and not have things 
> upgraded for them then they can point to the fully qualified 1.0.0 and

> decide when they want to upgrade to 1.0.1.
>
> I need people to be able to chose between having an exact version 
> dependency or a 'meta' version dependency which can change.
>
> 3rd party libaries will always be tagged at exact level.
>
> Any ideas?
> Alex
>
>
> -----Original Message-----
> From: John Gill [mailto:llignhoj@gmail.com]
> Sent: 18 September 2007 10:26
> 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
> --------------------------------------------------------
>
> 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.
>



--
Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/
http://incubator.apache.org/ivy/ http://www.xoocode.org/
--------------------------------------------------------

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.

Mime
View raw message