ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Gill" <llign...@gmail.com>
Subject Re: Resolving Dependencies not to patch level
Date Fri, 21 Sep 2007 13:14:36 GMT
I take it this is so you can exec something from ant that needs jni right? I
could be wrong, but I was under the impression that DLLs and SOs, need to be
in the real path operating system path and not the classpath.

You might be able to do this:

<exec ... >
  <env key="PATH" path="${env.PATH}:${basedir}/bin"/>
</exec>

Where bin is a directory where you have resolved to SOs to.

On 9/20/07, Foreman, Alex (IT) <Alexander.Foreman@morganstanley.com> wrote:
>
> 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.
>



-- 
Regards,
John Gill

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