Re: Open source ivy files project?

> 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?