Hi, I've been using (and liking) Ivy for a while now and have some thoughts on how the state of the Ivy world might be improved. I'd appreciate any feedback...
At work we have created our own Ivy repository. This is normal and works fine. However, building this repository is tedious and error-prone. For each Java package we want to use, I have to go through the same tedious steps: 1. Go download jfoobar-1.2.3.zip from http://www.jfoobar.com 2. Examine jfoobar to understand: 1. Which JARs are required, which are optional, etc. 2. What is an appropriate set of ivy configurations to define based on previous step 3. Determine which JARs in jfoobar are really part of jfoobar and which are simply required libraries included from some other project 3. Create an ivy.xml for jfoobar that defines the configurations and dependencies from step #2 (plus homepage, copyright, etc.) 4. Create a new ant project that performs the following steps: 1. Unpack jfoobar-1.2.3.zip 2. Extract the appropriate JARs (renaming them to remove revision numbers) 3. Extract the Javadocs and put into a javadoc.zip 4. Extract the sources and put into a sources.zip 5. Publishes the new ivy module to our local repository 5. Recursively perform this entire process for all dependencies found in step #2 6. Execute ant project from step #4 The real work is in steps #2 and #3. The tendency due to laziness is to just have a "default" configuration and dump all the JARs (whether part of jfoobar or not) into it. The result is, as before, a enormous CLASSPATH containing multiple versions of the same dependent libraries over and over again. I.e., nothing much has changed since before ivy. If instead you really try to pick apart all the extra libraries, create separate modules for them, etc. you are rewarded with a combinatorial explosion due to step #5. But at least you then have CLASSPATH sanity... So here's my dream: I want there to be an open source project somewhere out on the web that captures the end result of performing the above steps for any and all Java projects that exist. Imagine a project that does for Ivy what JPackage.org does for RPM. Some key goals of this would be: 1. Ivy definitions for zillions of Java projects already created and made available to Ivy users everywhere 2. Open source: multiple contributors, each maintaining the particular packages they know well 3. Does not require storing any JAR, ZIP, or TGZ files on the website itself, only a capture of the above steps' logic 4. For each package, we get a *standard* definition of the configurations available for that package 5. An easy way to configure my local Ivy to use this information I think goal #3 is important. This web site should contain meta-data, not copies of archives available elsewhere (but yes to MD5 checksums, etc.) Regarding step #5 there are a couple of possibilities... 1. There could be an easy way to use this info to automatically build/update your own, private repository (specifying exactly which projects you care about). 2. This is a little fancier... some way to simply include this website in your Ivy configuration using a (new) resolver. This resolver would download the corresponding instructions (perhaps just build.xml and ivy.xml files), build the Ivy module using ant, publish it to the local machine (in a new type of "cache repository"), and then find the module in the local "cache repository". This idea is only half-baked. But it seems like something is definitely needed. An unmaintained ivyrep and maven-only ibiblio are not cutting it for me. Thoughts? Thanks, -Archie -- Archie L. Cobbs
