以下は http://ant.apache.org/ivy/m2comparison.html の翻訳

IvyとMaven2の比較

Maven2と比較してどうなの？とは度々聞かれることである。ここに我々の意見を述べておこう。

ただ、明らかにこの手の比較はバイアスされる（ここはIvyのサイトだよ）けれども、できる限りフェアにいこう。このページに何か抜けがあったり間違いがあったりしたら知らせてほしい。またcodehausのMaven2機能比較ページを見てもよいだろう。これは別の視点を与えてくれる。

さらに、この話にはさまざまなディスカッションがなされている。その中でも among which the one triggered by spring contemplating about switching to maven is may be the more interesting.

しかしここでは、Maven2とIvyの大きな違いと思うところを指摘しよう。

木とリンゴを比較する

まず最初に、もっとも重要な違いというのは、それらが同じ種類のツールではないということだ。 Maven2はソフトウェアプロジェクト管理と統合化初ツールであるのに対し、Ivyは依存関係管理ツールであり、それはもっともポピュラーなビルド管理ツールであるAntと高度に統合されている。したがって、もう少し面白い比較というのは、Ant+IvyとMaven2になるかと思うが、これはこのページの範囲を大きく超えてしまう。ここでは依存関係管理にだけ集中しよう。

異なるコンセプト

Ivyはコンフィギュレーションという一つの概念に大きく依拠している。 Ivyにおいては、モジュールコンフィギュレーションというおのが、モジュールを使ったり見たりするための方法である例えば、あなたのモジュールに、テスト時とランタイム時のコンフィギュレーションがあるとする。しかしまた、mysqlとoracleのコンフィギュレーションも持つとする。はたまたhibernateｔjdbcのコンフィギュレーションも。それぞれのコンフィギュレーションでは必要なアーティファクト(jar, war, ...)が宣言されている。そして、それぞれのコンフィギュレーションでは他のモジュールへの依存を宣言し、どの依存コンフィギュレーションが必要であるかを宣言する。これをコンフィギュレーションマッピングといい、我々がソフトウェア開発においてしばしば直面するたくさんの問題に答える非常にフレキシブルな方法なのである。

Maven2は、スコープと呼ばれるものを持っており、テストスコープ、ビルドタイムスコープの一部として依存を宣言することができる。これらのスコープに依存することで、依存アーティファクト（Maven2では一つのモジュールにただ一つのアーティファクト）を得ることができる。スコープはMaven2ではあらかじめ定義されており、変更することはできない。 oracleスコープを定義することはできないし、 No way to indicate you need what has been declared to be needed in the runtime scope of your dependency in your compile one. すべては大理石の中に記述されている。

そしてこれが問題の発端となる。Matt RaibleがMaven2の依存についてブログに記述したように。

多くのライブラリのための非常に多くの不必要な依存がダウンロードされてしまいます。例えば、Hibernateは一群のJBoss Jarファイルをダウンロードするし、Display Tagは様々なWebフレームワークのJarをダウンロードします。私自身が追加した多くの依存のほとんどを削除していました。

Hibernateでは様々なキャッシュ実装、様々なコネクションプール実装が用いられる可能性のあることが問題で、これはスコープでは管理できない。しかるに、Ivyコンフィギュレーションでは、この種の問題に対するエレガントな解決を提供する。例えば、こｎケースでは、hibernateをIvyファイルとして扱い、依存性を次のように宣言すればよい。

<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->proxool,oscache"/>

これはproxoolとoscache実装と共にhibernateを得る場合である。

<dependency org="hibernate" name="hibernate" rev="2.1.8" conf="default->dbcp,swarmcache"/>

上はdhcpとswarmcacheを得る場合である。

ドキュメント

ツールを使う場合の重要な点はドキュメンテーションの量である。 Ivyでは、それらがブロークンイングリッシュで書かれている場合であっても、リファレンスドキュメントは広い範囲ですべての機能を網羅している、たくさんの例と共に。そしてまた、我々は、Ivyの新バージョンのたびにメンテナンスされるいくつかのオフィシャルなチュートリアルを提供している。我々はドキュメントを重視しているため、Ivy 2.0.0-alpha2からはオンラインバージョンも提供している。

Maven2では依存管理ドキュメントとしてどれを読めばよいのかを判断するのが少々難しい。せいぜい小さな紹介ガイドやpomリファレンスガイドの短いガイドを見つけ出せるくらいだろう。無料で取得できるMavenの書籍の中にある依存管理の記述でさえ、我々の視点から言えばほのかな光である。

衝突管理

衝突管理は、依存管理の重要な一部である。推移的依存関係を扱うなら、しばしば衝突に直面することがある。これについてはIvyは、お望みのことをしてくれる。あるモジュールにおいて衝突マネージャを使い、他の場所では別のものを使い、どのリビジョンを取得するかを決めることができる。必要であれば、あなた自身の衝突マネージャをプラグインすることもできる。

Maven2では衝突管理は極めてシンプルである。原則としては、最も近くの定義を取得するということ。したがって、あなたのモジュールがfoo 1.0に依存するのであれば、依存宣言を変更することなしにfoo 1.1を取得するように管理することはできない。これで構わないケースもあるだろうが、問題になるケースもあるだろう。

フレキシビリティ

Ivyでは多くのことが設定可能であり、他の多くのことがプラグイン可能である。依存リゾルバや競合マネージャ、モジュールでデスクリプタパーサー、最新リビジョンストラテジである。

Maven2はリポジトリプラグイン可能性も提供しているのだが、我々が知る以上のものではない。さらに、リポジトリコンフィギュレーションはIvyほどにはフレキシブルではない。リポジトリチェイニングもできないし、複数のリポジトリにおいてメタデータとアーティファクトを分離する方法もない。

パブリックリポジトリ

Maven2は、最初からMaven2リポジトリを利用できるようになっており、ここにはたくさんのモジュール（アーティファクトとモジュールデスクリプタ）が含まれている。ただ一つの問題は、モジュールデスクリプタは必ずしもチェックされたものではないということ。したがって、うまく記述されていない場合がある。 IvyはMaven2メタデータと互換性を持ち、デフォルトのパブリックリポジトリとしてMaven2のものを利用している。初心者が使うのには適当だからだ。

しかし、エンタープライズビルドシステムで、このようなパブリックリポジトリを使うのは推奨できない。 Ivyはパブリックリポジトリで提供されるデータを基盤としてあなた自身のエンタープライズリポジトリを作成するための、機能とドキュメントを提供している。