ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Thu, 17 Apr 2008 07:04:48 GMT
On Wed, Apr 16, 2008 at 8:54 PM, Archie Cobbs <> wrote:

> On Wed, Apr 16, 2008 at 1:17 PM, Jing Xue <>
> wrote:
> > I read the thread on the dev list, and was thoroughly interested in the
> > idea of a community-maintained public ivy.xml repository, because a
> > carefully defined ivy.xml provides a lot more value than the ones
> generated
> > from the pom, and would be something worth sharing.
> >
> > On the other hand, I'm not sure I see the value in the builder resolver.
> I
> > guess I'm having a hard time imagining a use case where I would prefer
> > building a 3rd party artifact locally rather than simply downloading it
> > through an ibiblio resolver, or from a company-level proxy repository.
> 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.

I think the problem is in the intention and the meaning of "building"
artifacts. If I understand correctly, Jing think that the builder resolver
will actually compile and package the artifacts, which wouldn't make a lot
of sense. What the "builder" actually do is simply download the artifacts
from where they are over the net, and when the jar is actually contained in
an archive, do the extract. For some artifacts like javadoc and sources
which are not always provided as an artifact usable by IDE, the builder can
actually extract the zip where the source files can be obtained, and
repackage the source files in a zip which can be used by an IDE. For
instance if you want to create a module for Ivy 1.4.1, you could get the
zips from <>, then unpack them
to get the main Ivy jars, and repack the sources and javadocs as usable
artifacts for IDEs.

The big advantage to do this automatically instead of manually is that the
work needed when a new minor version is released is usually minor: bump up
the version and update the sha1 and if the packaging hasn't changed you're
done! Then you can concentrate on metadata.


> 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? :-)
> -Archie
> --
> Archie L. Cobbs

Xavier Hanin - Independent Java Consultant

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