Steve Loughran wrote: > 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.
don't forget BSD's ports -- Stefano.
