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 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. 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. 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. 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. 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. Cheers. -- Jing Xue
