Apache Ivy™ / Apache Maven™ Comparison


We are frequently asked how Apache Ivy™ compares to Apache Maven™, so we have decided togives some insight about our opinion on the subject.

Obviously this comparison is biased (hey, you are on official Apache Ivy site :-)), but we'll try to keep it as fair as possible. Do not hesitate to add comment if you feel something is missing or false on this page. You can also have a look at Apache Maven2 feature comparison page on codehaus, which itself offers another point of view.

There have been also several discussions on the subject, among which the one triggered by spring contemplating about switching to maven is may be the more interesting.

But here is the points we think mainly differentiate Apache Ivy and Apache Maven.

Comparing plants and apples

First, the most important difference is that they aren't at all the same kind of tools. Apache Maven is a software project management and comprehension tool, whereas Apache Ivy is only a dependency management tool, highly integrated with Apache Ant™, the popular build management tool. So maybe a more interesting comparison would compare Apache Ant+Ivy vs Apache Maven. But this goes beyond the scope of this page which concentrates on dependency management only.

Different concepts

Apache Ivy heavily relies on a unique concept called configuration. In Apache Ivy, a module configuration is a way to use or to see the module. For instance, you can have a test and runtime configuration in your module. But you can also have a mysql and an oracle configuration. Or an hibernate and a jdbc configuration. In each configuration you can declare what artifacts (jar, war, ...) are required. And in each configuration, you can declare your dependencies on other modules, and describe which configuration of the dependency you need. This is called configuration mapping, and it is a very flexible way to answer to a lot of problems we face very often in software development.

Apache Maven on its side has something called the scope. You can declare a dependency as being part of the test scope, or the buildtime scope. Then depending on this scope you will get the dependency artifact (only one artifact per module) with its dependencies depending on their scope. Scopes are predefined and you can't change that. No way to create an oracle scope. No way to indicate you need what has been declared to be needed in the runtime scope of your dependency in your compile one. Everything here is written in the marble.

And this leads to some kind of troubles... as Matt Raible stated in his blog talking about maven2 dependencies:
There are a *lot* of unnecessary dependencies downloaded for many libraries. For example, Hibernate downloads a bunch of JBoss JARs and the Display Tag downloads all the various web framework JARs. I found myself excluding almost as many dependencies as I added.
The problem is that hibernate can be used with several cache implementations, several connection pool implementation, ... And this can't be managed with scopes, wheres Apache Ivy configurations offers an elegant solution to this kind of problem. For instance, assuming hibernate has an ivy file like this one, then you can declare a dependency like that: 
<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->proxool,oscache"/>
to get hibernate with its proxool and oscache implemetations, and like that: 
<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->dbcp,swarmcache"/>
to get hibernate with dbcp and swarmcache.

Documentation

An important thing to be able to use a tool is its amount of documentation. With Apache Ivy, even if they are written in broken english (would you have preferred well written french :-)), the reference documentation is extensive and covers all the features including many examples. We also provide some official tutorials which are maintained with the new versions of Apache Ivy. And since we consider documentation so important, we also provide online versions of documentation since version 2.0.0-alpha2.

With Apache Maven, it's a bit difficult to clearly know what can be considered as dependency management documentation, but we didn't managed to find much: some small introductory guides, short entries in the pom reference guide, and not really much more. Even in the maven book you can get for free on mergere website, the insight about dependency management is still light in our point of view.

Conflict management

Conflict management are an important part of dependency management, cause when dealing with transitive dependencies you often have to face conflicts. In this area, Apache Ivy let you do whatever you want: use one conflict manager in one module, another one elsewhere, decide which revision you will get, ... You can even plug your own conflict manager if you need to.

With Apache Maven, conflict management is quite simple: the principle is to get the nearest definition. So if your module depends on foo 1.0, none of your dependencies will ever manage to get foo 1.1 without a change in your own dependency declaration. It may be ok in some cases, it may not in others...

Flexibility

In Apache Ivy many things can be configured, and many others can be plugged in: dependency resolvers, conflict manager, module descriptor parser, latest revision strategy, ...

Apache Maven also offers repository pluggability, but not much more as far as we know. Moreover, repository configuration is much less flexible than with Apache Ivy: no repository chaining, no way to split metadata and artifacts in multiple repositories, ...

Public Repositories

Apache Maven comes out of the box configured to use maven2 repository, which contains a lot of modules (both artifacts and module descriptors). The only problem some may face is that module descriptors are not always checked, so some are not really well written.
Apache Ivy is compatible with maven 2 metadata, the default public repository used is also the maven 2 repository, which is fine for a good out of the box experience.

However, we don't recommend to use such a public repository for an enterprise build system, and as such Ivy provides features and documentation to build your own enterprise repository based (or not) on data available in the public repository.