Speaking for me, I agree that the maven repository is sometimes crapy. But how would you do better? If you think you can, please do.
Note anyway that it will never replace an internal repository that will always be much more secure (security = availability , integrity and confidentiality). On 02/04/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Wed, Apr 2, 2008 at 12:48 AM, Archie Cobbs <[EMAIL PROTECTED]> 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/ > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
