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, libXm.so is a symlink to libXm.so.3 which is a symlink to libXm.so.3.0.2. 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="libXm.so.3,libXm.so" 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 [mailto:[email protected]] Sent: Saturday, August 01, 2009 5:15 PM To: [email protected] Subject: Solution to native dependencies with Ivy ivy-user, 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: http://www.cooljeff.co.uk/2009/08/01/handling-native-dependencies-with-apache-ivy/ 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. Regards, Jeff ---------------------------------------------------------------------- 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.
