ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <anto...@gmx.de>
Subject Re: Open source ivy files project?
Date Wed, 02 Apr 2008 03:14:33 GMT
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message