ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: C++ and Ivy [WAS: Re: [DISCUSS] EasyAnt ...]
Date Thu, 10 Jan 2008 17:26:24 GMT
On Jan 10, 2008 6:13 PM, Dominique Devienne <ddevienne@gmail.com> wrote:

> > On Jan 10, 2008 10:34 AM, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > > On Jan 10, 2008 5:13 PM, Dominique Devienne <ddevienne@gmail.com>
> wrote:
> > > it so that my involvement with Ant took a back step, and I'm mostly
> > > watching from afar what's going on in Ant. I've never used Ivy for
> > > example. I'd probably have replaced my dependency stuff with Ivy by
> > > now, although my stuff was C++ aware and was pulling not just jars
> > > with also C++ headers and libraries, packaged sources of dependent
> > > modules for debugging, etc...
> >
> > BTW Ivy is language agnostic, so you can use it for non java dependency
> > management. But this is out of topic.
>
> Can I abuse of your time to explore this a little more Xavier? Being
> language agnostic doesn't necessarily translate in being usable to
> deal with natively compiled and linked dependencies. The ad-hoc system
> I built wasn't agnostic. When a dependency had native code associated
> to it (the JNI glue code and supporting native libs it depended upon)
> as described in the published artifact descriptor, the system knew to
> look for foo-module-win32.zip in addition to foo-module.zip, if you
> were building on win32, and each platform was getting its own specific
> binaries. Then once the dependency was expanded, in addition to
> automatically adding the dependent JARs on the classpath, it also
> appended to the compilation include path, link library path, and
> runtime PATH and java.library.path, and all transitive dependencies of
> the current project. The common build could then reference all these
> paths by well know ids, with no further configuration. The system
> depended on a fixed and well know hierarchy for the artifact zips.
>
> Given the agnostic nature of Ivy, how would one go about replicating
> the kind of system I describing above on top of existing Ivy? Note
> that I'm pretty ignore of Ivy, and haven't taken the time to explore
> the doc before asking this question, so feel free to brush me off to
> find the answers myself ;-) But since I have your attention, I thought
> I'd try to get advice from the Ivy man directly ;-) Thanks, --DD

Sure :-) But I'm not *the* Ivy man, only *one* Ivy man :-)

First what I mean by language agnostic is that Ivy can handle any kind of
artifacts, and not only jars. So in your case you can easily declare that
your module publishes several artifacts, one being the jar, and the others
being platform specific zips. Then you can split your platform specific zips
in separate configurations (one by platform). This declaration goes in the
module ivy file in the repository. Then you can ask Ivy to resolve the
platform specific configuration you need depending on the platform you make
your build on. And once you get the zip on your local filesystem you can do
whatever you want with it like you did before, Ivy being used only for
provisioning.

Is this clear enough for an Ivy "ignorant"?

Xavier


>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


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

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