As you say, the tools are solving slightly different problem. But those different tools include in some way a dependency management (If I use that version of this library, I need also that version of this one). Even it is not their first purpose, I guess that at some level they rely on a "dependency management module". I think it's the essence of such module that we have to consider when positioning ivy.
Note also that I have colleagues that use ivy as a 'distribution/auto-update' tool. They want to distributes the result of our continuous build to the tester. He provided them ant, the ivy lib, and the ant script that retrieve the latest built version and launch the application. Maybe unusual use case, but a real one. By the way, did you known if the Java webstart underlying protocol includes dependency meta-data information? There is also some similar systems in eclipse : they manage dependency against plugins (or features). Steve, Tomorrow, I will start a wiki page with the list "dependency management modules". May I copy extract from your mail to this page? Gilles > -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 15, 2006 12:25 PM > To: [email protected] > Subject: Re: Dependency standards > > Gilles Scokart wrote: > > > > > > > > When reading some general info about apache > > (http://www.apache.org/foundation/how-it-works.html#management ) I > > have seen one of the sentence of The Apache Way : "faithful > > implementation of standards". > > > > What does it means for ivy? What are the existing standard > (official > > standards or de-facto industry standards) related to > dependency management? > > > > Making a search, I found JSR 277. > > There is also the defacto standards apt, rpm and maven repository. > > > > What else? > > > > Don't you think that such inventory, with description and the its > > relation with ivy would have his place on the wiki? > > Yes, that would be really good. Don't forget OSGi. There was > a really good OSGi talk at apachecon eu this year. > > > All these tools are trying to solve slightly different problems. > > > rpm: manage the state of a single machine, downloading and installing > the requested version of an artifact, uninstalling its precedessor. > > apt: manage the state of a single machine, downloading and installing > the requested version of an artifact, uninstalling its > precedessor. If > the artifact is only published as source, compile it based on > scripts in > the .deb package > > They act on the global state of the system, and are primarily > a redist > mechanism. Wonderful though they may be. > > ivy: manage the dependencies of a build, and across builds. pull down > artifacts into a cache for efficiency. > > m2: manage the dependencies of a build, and across builds. pull down > artifacts into a cache for efficiency. With a whole project's > metadata > in the pom, on demand-compilation is possible, as is continous > integration without the need to configure the CI server any further. > > They are build time. and because you can have different versions > side-by-side in the filesys, that is what you get. What > neither of them > do is enforce a hard split between compile time interfaces > and runtime > artifacts, or provide any runtime management of JARs you > load. They dont > dictate how you use the JARS. > > OSGi: manage interaction between deployed artifacts. You can have > different versions in different classloaders; only interface atifacts > are exported, while impl. artifacts are kept private. Its an > application > architecture, not a build system. It has limitations (RMI dynamic > classloading is troubled; hot swapping is only slightly > possible), but > it tells you how to design your app. Its pretty nice, although your > modules are still coupled at the interface class level, which > is fairly > brittle. Tools that integrate by passing XML content around > in process > (Cocoon, netkernel) are more loosely coupled as there is no > sharing of > artifacts between modules, just XML content. > > Also: the Perl CPAN and ruby gems systems. > > -steve
