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+downstream+release On 17/04/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Wed, Apr 16, 2008 at 8:54 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 16, 2008 at 1:17 PM, Jing Xue <[EMAIL PROTECTED]> > > 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/ > -- Gilles Scokart
