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
