ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@anyware-tech.com>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Thu, 17 Apr 2008 09:20:02 GMT
Le jeudi 17 avril 2008, Gilles Scokart a écrit :
> 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 :-)
>
> [1]
> http://article.gmane.org/gmane.comp.java.jmock.user/972/match=maven+downstr
>eam+release

This idea behind this repository is getting more clear to me too. :)
Then I cannot not compare it to Linux distributions. It reminds me an article 
about debian packager, about the different responsabilities about developping 
and packaging.

Then I wouldn't make a difference in trust between the maven community and an 
ivy round up community. Their main job is about packaging, so we have to 
trust both for that. If I can trust the ivy roundup community to produce a 
reproductible build, then I would trust the maven community to execute a 
reproductible build.
This make me think of gentoo VS ubuntu. The first one is just packaging build 
script, the other one is packaging build. It sometimes can make sense in the 
native world, but not in a jvm world.
On the other hand, maintaing build scripts is definitively a good idea. Just 
like the debian/ubuntu community is maintaing their build scripts. As said 
Xavier it helps the community to maintain a module along with the upgrading 
versions. I would consider the Ivy RoundUp Repository being a repository for 
maintainers more than for Ivy users. I think that Ivy users should only see 
jars.

That discussion makes me also think of the Orbit community. There are building 
and releasing entire osgi bundle repositories. See for instance:
http://download.eclipse.org/tools/orbit/committers/drops/I20080416020842
Thought I don't know how practical it is.

Nicolas

>
> On 17/04/2008, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > On Wed, Apr 16, 2008 at 8:54 PM, Archie Cobbs <archie@dellroad.org> wrote:
> >  > On Wed, Apr 16, 2008 at 1:17 PM, Jing Xue <jingxue@digizenstudio.com>
> >  >
> >  > 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
> > <http://www.jaya.free.fr/downloads/ivy/1.4.1/>, 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
> >  http://xhab.blogspot.com/
> >  http://ant.apache.org/ivy/
> >  http://www.xoocode.org/



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Mime
View raw message