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