ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jing Xue <jing...@digizenstudio.com>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Sat, 19 Apr 2008 04:55:38 GMT
On Wed, Apr 16, 2008 at 01:54:42PM -0500, Archie Cobbs wrote:
> 
> The problem is that not all artifacts are available as URLs. Many times,
> they are packaged up inside a tar.gz file and the only way to get at them is
> to extract them.
> 
> So without builder resolver, someone has to:
> 
>    1. Build and maintain an online repository that has huge disk space
>    (and bandwidth) requirements
>    2. Perform the manual download, extract, and publish steps every time
>    a software has a new release
> 
> With builder resolver, #1 goes away entirely and #2 is reduced to updating a
> SHA1 checksum (common case).
>
> If you don't think #1 and #2 matter, then why aren't you volunteering to do
> them for us? :-)

Well I just sent you an email to apply for joining the project, because
I felt that I could help out in maintaining the repo. 8-)

I must confess, however, even after all the clarification from everyone
about what "build" means, I'm still not 100% convinced about the builder
resolver. Let me try and explain:

There is already the maven2 repository that everybody using ivy these
days pretty much relies on. So most - 99% - of the artifacts are already
there, instead of having to be downloaded and extracted from the
original distribution packages. Speaking from my experience, I have only
had a few occasions where I had to manually download jars and put them
in my proxy repository - for instance, the notorious jta jar that
ibiblio cannot legally redistribute, thanks to Sun's license terms.

On the other hand, IMHO, the gap between an ideal ivy user experience
and the current state of affair comes from two issues:

1. The inconsistent quality of the metadata files in the maven2
repositories. Sometimes they are simply broken, sometimes else they are
not carefully written and come with, for example, unnecessary
dependencies.

2. The limitations posed by the POM syntax itself leads to
overly-simplified pom.xml's, which in turn prevents the auto-generated
ivy files from leveraging all the expressiveness that ivy provides.

So far, my understanding is that those issues are being addressed by the
ivy community with ivy files manually created, optimized and put in some
proxy repository (or a local file system resolver). A proxy repository
can also be used to provide artifacts that aren't directly available
from the public repositories. The proxy repo maintainer can (and perhaps
should) take up the task of preparing these artifacts. The good thing
about this approach is, they only need to be prepared once and then kept
in the proxy for good, instead of having to be involved in every build
process.

So, the proxy-based approach works well enough at least for me. And that
is why I said earlier that I would be immensely interested in a
community-maintained ivy metadata repository that does not require a
special resolver to access, i.e., can be hooked in with a dual resolver.
That would make it a great _and_ easily accessible channel for all
the ivy users to share manually optimized metadata.

Cheers.
-- 
Jing Xue


Mime
View raw message