ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Thu, 17 Apr 2008 08:03:55 GMT
Jing was not the only one to misunderstand the "building" term... I did also.

Actually now the ivy roundup resolver as a resolver that allow you to
take the meta-data from the roundup repository and take the artefact
directly from the project distribution site!

And then, I'm suddently much more enthousiast about it!

It make me think to a thread that I read some time ago on the jmock
mailing list [1].
Initially, the jmock team didn't wanted to distribute themself their
library in a maven repository.  Their resistance was understandable
and had a right justification.  They would preffer someone else to
redistribute. They finaly did it themself (after some external
contributions) because of the pression of the maven users and because
it is better for the user to receive the library directly from the
team that build it.

With the ivy roundup aproach the user has to trust the ivy roundup
community to setup the right meta-data (as a user, I would have a to
look at how this community work, but It is possible that I could trust
them), and then I would have to trust the author of the library (and
if I use their library, I guess that I trust them.

With a maven2 redistribution aproach, I need to to trust the maven2
community for both the meta-data and the binaries.  It looks to me
more "risky" to trust.

All that to say : you should remove the image of "building".  The
resolver is a tool to get dependencies from their original
distributions site.  That should be reflected in the term you use if
you want to keep me enthousiastic :-)


On 17/04/2008, Xavier Hanin <> wrote:
> 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.
>  Xavier
>  >
>  > 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

Gilles Scokart

View raw message