ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Sat, 19 Apr 2008 07:03:00 GMT
On Sat, Apr 19, 2008 at 6:55 AM, Jing Xue <jingxue@digizenstudio.com> wrote:

> 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

I don't think it's that close to 100%. Some modules are missing due to
license restriction, others are missing because their developer now have
their own repo, which is not synced with maven central. So I'd rather say
that 99% are available in "one" maven2 repo somewhere. And this makes a
difference, especially for newbies. With Ivy roundup we can centralize
modules coming from several sources, most of which will be maven 2 repo,
others will be download sites. Sometime it will be mixed, when only the
binary jar is available on a maven 2 repo, and the source and javadocs can
only be obtained through a download site.

>
> 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.

jta.jar is not available java.net maven repository, so we can even provide
access to this one in IvyRoundUp.

>
>
> 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.

Agreed. And don't forget name inconsistencies, which is a real pain for
newcomers.

>
>
> 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.

+1


>
>
> 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.

Good, but to maintain your proxy when a new version is out you have to
reproduce very similar steps. I think the idea of roundup repo comes from
this experience, feeling that you lose time because you're missing
"distilling" instructions. So with Ivy roundup it's super easy to setup a
proxy: the proxy use Ivy roundup, the end user use the proxy. It's not the
approach taken yet, because most people starting to use a dependency manager
don't want to have to setup a proxy or server or whatever. They want
something that works out of the box with resources available over the net.
That's why I think the roudup repo AND the "builder" resolver make sense.
Now I agree that pretty quickly we'll need some other tools than the
"builder" resolver to access the repo. But I think the value is not in the
resolver, the value is in the repository of Ivy files AND "distilling"
instructions.

>
>
> 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.

With only Ivy files, you can hit the problem of naming inconsistencies. Ivy
namespaces can help, but I'm not sure it can address all problems. The
roundup approach has no limitation, except the time required to create the
metadata.

Xavier


>
>
> Cheers.
> --
> Jing Xue
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message