ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: Solution to native dependencies with Ivy
Date Sun, 02 Aug 2009 16:33:18 GMT
I have been using the configuration approach for over a year in my enterprise environment.
 All of the modules built by my company have all applicable platforms as configurations with
each artifact (that is platform specific) showing which conf (platform) it is applicable for.
 For jars and such, no configuration specification is used to show it is applicable for all
configurations defined in this module.  All of the dependencies in my modules use the following
conf mapping, "*->@" to propagate the platform configuration down to the children for transitive
dependencies.  In other words, when the end user asks for the win32 conf of module A, then
he will get the win32 configuration of all of its transitive dependencies too.

The end user controls which platform configuration he wants.  The default is to examine the
platform being used to perform the ant build and specify that as the configuration name to
be retrieved.  If a user wants to get a different platform then what he is running the build
on or if he wants to get multiple platforms at once, then he simply sets an ant variable to
define which configurations he wants.  If a module is an install anywhere module that can
produce a cross platform installer, then it might want all configurations (platforms) at once.
 That is achieved with the wildcard when specifying the configuration (platform) desired.

For thirdparty modules, we have setup our own thirdparty repo internal to our network.  We
do not use any public IVY or MAVEN repo as our legal department wants to have complete control
over the thirdparty dependencies we ship with our products.  This means I manually get thirdparty
dependencies from their webpage source and add it to our thirdparty repo.  This allows me
to fully control the ivy.xml file used and add in platform configuration names to match our
own modules described above.

On a unix environment, symlinks are typically used for *.so files to have different names
for the same thing.  For example, is a symlink to which is a symlink to  It can be important to retain this symlinking for modules higher up in the
dependencies hierarchy from being able to link and build.  Therefore, we have setup a system
to maintain these symlinks after a retrieve in IVY.  We have added an extra attribute called
"aliases" in our ivy.xml files like:

<artifact name="libXm" ext="so.3.0.2" type="bin" ext:aliases="," conf="linux32"/>

I have created an IVY trigger using "post-retrieve-artifact" (which didn't exist until I requested
its creation in IVY 2.1) so that the trigger can check if the extra "aliases" attribute exists
and then execute the unix "ln" command to recreate the symlinks on the end users machine.

Finally, by using configurations to handle platforms, it makes it more difficult to use configurations
to subset your modules as demonstrated by the IVY documentation where is uses "runtime" and
"compile" as example configuration usages.  If I have my modules subsetted by platform configurations
AND I also want to subset them by "runtime" and "compile" time usages, then I don't want to
have to define n*m number of configurations, win32-runtime, win32-compile, win64-runtime,
win64-compile, linux32-runtime, linux32-compile, etc.  This is why I have also requested configuration
intersection.  That allows an end user to request only win32 artifacts that are also only
applicable for runtime, by using the configuration intersection notation:  win32+runtime.
 This is a controversial subject so please see all of the postings in the last week where
I was trying to describe my use case.

In summary, I have been very successful in using configurations to handle all of my platform
specific issues.  It works very nicely.

Shawn Castrianni

-----Original Message-----
From: Jeffrey Sinclair [] 
Sent: Saturday, August 01, 2009 5:15 PM
Subject: Solution to native dependencies with Ivy


The handling of artifacts to populate the java.libary.path has cropped
up a couple of times on the mailgroup and there is an outstanding JIRA
relating to this [IVY-600].

I'm finding that more people are being hit by this, in particular in
Eclipse through IvyDE. I've come up with a solution that I feel will
work well for both Ivy and IvyDE:

As described in the blog entry, I'd like to propose a mixture of using
types as well as a new attribute on the artifact named platform.

I'd like to put a proof of concept together and hence would be grateful
for any feedback on my proposal and evaluation of existing solutions.



This e-mail, including any attached files, may contain confidential and privileged information
for the sole use of the intended recipient.  Any review, use, distribution, or disclosure
by others is strictly prohibited.  If you are not the intended recipient (or authorized to
receive information for the intended recipient), please contact the sender by reply e-mail
and delete all copies of this message.

View raw message