antからプロジェクトの依存関係を管理するための最良の方法について考えていました。Maven AntタスクとIvyの長所と短所は何ですか？
質問する
16055 次
8 に答える
41
あなたがやりたいことは、依存関係管理を既存の Ant プロジェクトに追加することなので、まさにそれが Ivy が設計した目的です。依存関係の管理は Maven の大部分を占めていますが、すべてではありません。Maven は、依存関係に加えて他のいくつかのことを行うプロジェクト指向のツールです。Maven に移行して追加の Maven 機能も使用することを計画している場合は検討する価値がありますが、Ant をスピンオフするためだけに使用する場合は少し多すぎます。
依存関係の種類と、それらがどのように動作するかについての期待も違いを生みます。サードパーティの依存関係を取得することは、Maven ではほとんど簡単ですが、Ivy は独自の依存コンポーネントの再構築に優れています。どちらの場合も、ツールは適切なビルド、バージョン管理、およびリポジトリポリシーを提供しません。これらは依然としてあなた次第であり、構成を正しく行うために必要です。
于 2008-11-25T21:11:42.373 に答える
40
Ant + Ivy == 人々が必要に応じて施設を利用するキャンプ場。
Maven == サービスの提供を誰かに頼るリゾート。
ビルド/統合の経験が不足しているチームにとっては Maven の方が簡単ですが、チームが Maven 標準から逸脱する必要がある場合、チームはグルーヴィーな gradle に手を伸ばしていることに気付くでしょう。
Ant + Ivy はプロジェクトの開始に時間がかかりますが、チームにビルド/統合の経験があれば、コードの開発とリリースに合わせてビルド システムを調整できます。
エンジニアリング... テクノロジー企業では、私は常にリゾートではなくキャンプ場のソリューションを求めています。
Ant と Maven の両方が、ビルド レシピを表現する言語として XML を選択していることは驚くべきことです。Java コミュニティはその XML に固執しています...
于 2009-05-07T02:51:50.447 に答える
8
Ivy + Antは、はるかに柔軟です。Ivyは依存関係の管理、期間を実行しますが、Mavenよりも非常に優れています。また、Antを使用すると、必要なビルドシステムをほぼまとめることができます。
Mavenは、「ライフサイクル」（コンパイル、テスト、パッケージ化など）、ファイルが存在する場所など、すべてを制御しようとします。「Mavenway」が気に入らない場合は、プラグインなどをカスタマイズして楽しんでください。
Mavenは、誰も尋ねなかった質問に対する答えです。Antスクリプトを書くことは難しくありません、そしてIvyはあなたにMavenより良い依存関係管理を与えます。Ivyを動作させることができなかったという以前のコメントのいくつかに混乱しています。Ivyは、Mavenよりも起動して実行するのがかなり簡単です。
Spring Frameworkは、ビルドプロセスでIvyを使用します。それはアイビーに対するかなりの自信の投票と見ることができると思います。
于 2010-05-03T21:46:28.463 に答える
8
このブログ投稿は、OP が探しているものを正確にカバーしていると思います。
于 2010-01-18T10:02:15.140 に答える
7
長期的な目標が Maven を使用してビルド プロセス全体を管理するように移行することである場合 (新しいグリーンフィールド プロジェクトではこれを行う可能性があります)、Maven の pom.xml ファイルを使用して、Ant build.xml に代わって依存関係を管理することを心からお勧めします。ファイル。最終的には、グリーンフィールド プロジェクトとレガシー プロジェクトの両方が依存関係を管理するために同じメカニズムを使用することになります。そして、Ant build.xml ファイルの依存関係を Ivy よりも Maven の方が適切に管理していることがわかりました。
フラグシップ ビルド ツールとして Maven を採用する前に、開発者に Ivy を既存の Ant build.xml ファイルと組み合わせて使用する試みをしてもらいました。これは非常に苛立たしい経験であり、すぐに Ivy を拒否することになりました。Mavenの採用を進めました。私たちのグリーンフィールド プロジェクトは、ストック Maven アプローチなどで構築され始めました。
しかし、私は Ant レガシー プロジェクトに戻り、Maven Ant タスクを使用してクラスパス定義を定義し始めました (場合によっては、pom.xml から引き出された他の Ant プロパティ定義も)。これは最高の経験であることが判明しました。既存の Ant build.xml ファイルをわずかに変更するだけで、Maven ant 統合を使用して build.xml ファイルで使用されていたクラスパスを定義できます。プロジェクトに必要なすべての依存関係は、付属の pom.xml ファイルで定義され、build.xml ファイルに組み込まれた Ant タスクを介して Maven によって処理されます。
Maven スコープを使用してクラスパス定義を微調整し、コンパイル、単体テストの実行、またはパッケージ化などに適した定義を確立できます。また、pom.xml ファイルで定義された要素のほとんどは、build.xml ファイル内の Ant プロパティとして参照できます。
実際、Maven の Ant タスクでは、Ivy が存在する実行可能な理由さえありません。
于 2009-03-01T01:50:09.670 に答える
5
Maven を ivy/ant と比較することは、スマートフォンを電信に例えることです。
ビルド インフラストラクチャで実際に永続的な効果を活用したい場合は、Maven を使用することをお勧めします。これは、すべてのソフトウェア プロジェクトまたはその他のソフトウェアに似たプロジェクトが直面するすべてのプロセスとタスクを予測して抽象化するためです。私は多くのプロジェクトに参加しましたが、あなたのプロジェクトがより複雑で、より多様で、より異質なものになれば、Maven プロジェクト構成のシンプルさをさらに賞賛するでしょう。確かに、それは複雑になりますが、アイビー/アリ主導のプロジェクトと比較して複雑ではありません.
Maven の主な利点は、「設定より規約」 (http://en.wikipedia.org/wiki/Convention_over_configuration) であり、非常に重要なパラダイムです。要するに、これは、明白/些細/ありふれたことを知る/構成する必要がないことを意味します。Maven とそのすべてのプラグインには多くのデフォルト設定が付属していますが、特別なニーズに合わせてプロジェクトを構成するオプションが常にあります。一方では、Maven を使用すると、プロジェクトを非常に簡単かつ迅速にセットアップできます。一方、最小限の労力でニーズに合わせて成長中のプロジェクトをカスタマイズできます。Maven の背後にある主要な概念を理解していれば、すべてのプロジェクトだけでなく、一般的なソフトウェア開発プロジェクトではないプロジェクトも活用できます。
過去に、私は多くの ant スクリプトを書き、次の Maven で ant が嫌いになりました。欠点の 1 つは、常にスクリプトをコピーして自分で繰り返し、繰り返さないタスクを繰り返さない ant タスクを開発することです...そして主な欠点は、大きくなる ant スクリプトが特に保守できなくなる傾向があることです。 12 人のアリ オタクがお互いにアリ スクリプトを宣伝したい場合。
多くのアリ愛好家は、アーティファクトのコピーやビルドメッセージの出力などの些細なことを全体的に制御することに苦しんでいます。しかし、Maven の重要な概念はこれらの些細なことを隠すことであるため、Maven がカスタマイズのニーズを制限するという伝説は永遠に生き続けます。しかし、心配しないでください、それは伝説です! これで、私の最初の声明がようやく理解できました。すでに解決済みの些細なことに煩わされる必要はありません。
たぶん ivy/ant は単純なプロジェクトのオプションですが、複雑に成長するプロジェクトには単純さと慣例が必要です。そうしないと、ますますメンテナンスの問題に圧倒されます。特に、グローバル プロジェクトに多数の依存プロジェクト、テクノロジ、および異種製品パーツがある場合、ant スクリプトの開発とテスト、または依存関係の問題の解決に費やす時間とお金がありません。
Ant は Maven の統合を提供します。この統合は、ant で成長したプロジェクトで maven をテストおよび操作するためによく使用されます。より多くの問題が発生するため、この愚かなアプローチは避けてください。代わりに、アリとその痛みにとどまるか、完全に Maven に移行します。
移行コストについて疑問がある場合は、Maven-Ant-Plugin によって異なる世界を統合する逆の方法を使用することをお勧めします。この標準プラグインを使用すると、あらゆる Ant スクリプトを簡単に実行できます。確かに、それはしばらくの間レガシー ソリューションですが、前任者の巨大な歪んだコメントなしの ant スクリプトのメガ行を理解するのに必要なだけの時間を与えてくれます。
次に、maven の次の利点を称賛します。ドキュメントは、使用するすべての maven プラグインの一部であるため、構成のドキュメントはほとんど必要ありません。
ですから、私は Maven-Antagonist であったことを告白します。
于 2012-01-26T17:59:25.797 に答える
2
Ivy の利点の 1 つは、さまざまな種類のリポジトリを使用できることです。通常、Maven は使用するリポジトリの形式に非常に厳格です。私が知っているのはそれで全てです。
于 2008-11-25T21:02:49.193 に答える
1
Ivyのドキュメントを2日間読んだばかりですが、何か選択できる場合はMAVENを使用してください。アイビーは完全で、私が知る限りゴミを出します。ビルドに組み込むために2日を無駄にし、今は損失を減らしています。なんで？
- アイビーは依存関係の管理における中途半端な試みです
- アイビーのドキュメントは冗談です
- アイビーの例とチュートリアルは役に立たない
「構成」（Mavenプロファイルとして読み取る）を導入するとすぐに、Ivyは必要のないあらゆる種類のジャンクをダウンロードして失敗し始めました。Ivyのドキュメントはまったくの冗談です。比較すると、Mavenのドキュメントは夢のように読めます。Ivyのドキュメントがどれほど浸透しにくく、ひどく書かれているかの例が必要な場合は、構成のリファレンスページを参照してください。これらはあらゆるビルドの重要な部分ですが、Ivyでは、考えた後、うまく設計されていないようです。
于 2010-04-09T21:13:13.990 に答える