Hello Archie,
I see two issues here. One is to find volunteers contributing for a work
of description. The other is to find a balance between very simple
configurations and very complicated ones.
There are potentially a lot of different dimensions along which one
could define configurations. For instance support for JDK 1.4, 1.5, 1.6,
support for different operating systems, for different human languages, ...
When I create descriptors at work, I have decided that all projects
which are hosted at sourceforge, for instance junit, have sourceforge as
organisation. This is arbitrary, but the legal status of the different
sourceforge projects is not clear to me.
So people creating descriptors will have to make a lot of decisions for
which there are no clear guidelines.
I remember that at one point in time I was reading the emails of the
repository list of apache, and for various reasons I have seen cases
where people were asking the republication of an existing POM. This can
happen to to an ivy repository. I am not sure how this should be handled.
Regards,
Antoine
Archie Cobbs 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?
Thanks,
-Archie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
