Re: Open source ivy files project?

> On Wed, Apr 2, 2008 at 12:48 AM, Archie Cobbs <archie@...> wrote:
>
>  > 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?
>
>
> I think steps #2 and #4 will be less and less necessary in the future. Most
>  projects are now available on a public maven  repository. This means that
>  you can at least get their jar already unpacked and available on the web,
>  and most of the time you can also get their sources and javadocs zipped. So
>  the real problem IMO is metadata and repositories cleaness/stability. As I
>  already said, I'm far from opposed to see this kind of public Ivy repository
>  emerge, I just think it's too early for the Ivy committer team to get
>  involved, while we still have quite a lot of work before releasing Ivy 2.0.0
>  final and IvyDE 1.3.0 final. But I speak only for myself.
>
>  Xavier
>
>
>
>  >
>  >
>  > Thanks,
>  > -Archie
>  >
>  > --
>  > Archie L. Cobbs
>  >
>
>
>
>
> --
>  Xavier Hanin - Independent Java Consultant
>  http://xhab.blogspot.com/
>  http://ant.apache.org/ivy/
>  http://www.xoocode.org/
>