| Deletions are marked like this. | Additions are marked like this. |
| Line 39: | Line 39: |
|
多くのライブラリのための非常に多くの不必要な依存がダウンロードされてしまいます。 例えば、Hibernateは一群のJBoss Jarファイルをダウンロードするし、Display Tagは様々なWebフレームワークのJarをダウンロードします。私自身が追加した多くの依存のほとんどを削除していました。 |
多くのライブラリのための非常に多くの不必要な依存がダウンロードされてしまいます。 例えば、Hibernateは一群のJBoss Jarファイルをダウンロードするし、Display Tagは様々なWebフレームワークのJarをダウンロードします。私自身が追加した多くの依存のほとんどを削除していました。 |
| Line 64: | Line 64: |
|
Maven2では依存管理ドキュメントとしてどれを読めばよいのかを判断するのが少々難しい。 せいぜい小さな紹介ガイドやpomリファレンスガイドの短いガイドを見つけ出せるくらいだろう。 無料で取得できるMavenの書籍の中にある依存管理の記述でさえ、我々の視点から言えばほのかな光である。 |
|
| Line 65: | Line 68: |
| With maven2, 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. | == 衝突管理 == |
| Line 67: | Line 70: |
|
== 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, 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. |
衝突管理は、依存管理の重要な一部である。推移的依存関係を扱うなら、しばしば衝突に直面することがある。 これについてはIvyは、お望みのことをしてくれる。 あるモジュールにおいて衝突マネージャを使い、他の場所では別のものを使い、どのリビジョンを取得するかを決めることができる。 必要であれば、あなた自身の衝突マネージャをプラグインすることもできる。 |
| Line 70: | Line 75: |
| With maven2, 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... |
Maven2では衝突管理は極めてシンプルである。 原則としては、最も近くの定義を取得するということ。 したがって、あなたのモジュールがfoo 1.0に依存するのであれば、依存宣言を変更することなしにfoo 1.1を取得するように管理することはできない。 これで構わないケースもあるだろうが、問題になるケースもあるだろう。 |
| Line 72: | Line 80: |
|
== Flexibility == In Ivy many things can be configured, and many others can be plugged in: dependency resolvers, conflict manager, module descriptor parser, latest revision strategy, ... |
== フレキシビリティ == |
| Line 75: | Line 82: |
| Maven2 also offers repository pluggability, but not much more as far as we know. Moreover, repository configuration is much less flexible than with Ivy: no repository chaining, no way to split metadata and artifacts in multiple repositories, ... |
Ivyでは多くのことが設定可能であり、他の多くのことがプラグイン可能である。 依存リゾルバや競合マネージャ、モジュールでデスクリプタパーサー、最新リビジョンストラテジである。 |
| Line 77: | Line 85: |
|
== Public Repositories == Maven2 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. Ivy being 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. |
Maven2はリポジトリプラグイン可能性も提供しているのだが、我々が知る以上のものではない。 さらに、リポジトリコンフィギュレーションはIvyほどにはフレキシブルではない。 リポジトリチェイニングもできないし、複数のリポジトリにおいてメタデータとアーティファクトを分離する方法もない。 |
| Line 81: | Line 89: |
| 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. |
== パブリックリポジトリ == Maven2は、最初からMaven2リポジトリを利用できるようになっており、 ここにはたくさんのモジュール（アーティファクトとモジュールデスクリプタ）が含まれている。 ただ一つの問題は、モジュールデスクリプタは必ずしもチェックされたものではないということ。 したがって、うまく記述されていない場合がある。 IvyはMaven2メタデータと互換性を持ち、デフォルトのパブリックリポジトリとしてMaven2のものを利用している。 初心者が使うのには適当だからだ。 しかし、エンタープライズビルドシステムで、このようなパブリックリポジトリを使うのは推奨できない。 Ivyはパブリックリポジトリで提供されるデータを基盤としてあなた自身のエンタープライズリポジトリを作成するための、機能とドキュメントを提供している。 |
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はパブリックリポジトリで提供されるデータを基盤としてあなた自身のエンタープライズリポジトリを作成するための、機能とドキュメントを提供している。