Ant自体はMavenと比較できないという意見をよく耳にします。 ただし、Ant + Ivyは既にMavenと競合できます。 これは部分的に真実です。
*これを書きました、覚えているので、Apache自身がMavenの時が来たと言っていたので、Antから離れてみてください。 しかし、彼は探しているものを見つけることができませんでした。
残念ながら、ほとんどの企業/プロジェクトでは、ビルド管理などの側面が開発者自身であることを誰もが知っています。 したがって、インターネットに関するこの主題に関する開発者の意見が支配的です。 両方のシステムを使用するすべての長所と短所を詳細に分析した多くの記事を読みましたが、悲しくなりました。 これらの記事の主な目標は、コードをコンパイルすることでした。 さて、時々、アーカイブ、インストール、およびFTPへのアップロード、またはTomcatへの展開を行う必要があります。 もちろん、便利な依存関係管理は非常に便利な機能であるため、考慮されます。 そしてそれだけです。 そして、Ant + IvyはMavenと比較し始めます。
多くの人にとって、DEVとQAのほかに、TL、PM、PO、PSO、サポート、CPE、L10N、インストール、デザイナー、およびコンテンツが由来する他の多くの場所があり、それらも製品配布の一部になるはずであることに驚くでしょう。 この発見に基づいて、DEVにはプロセスを効果的に残す力がないことが明らかになりました。 したがって、大規模なプロジェクトでは、個別のビルドファクトリチームが存在します。 しかし、これはまったく異なる話のトピックです。
トピックに戻ると、この記事の要点に到達しました。 Antは単なるビルドツールであり、Mavenは既にプロジェクト管理ツールです。
さて、今、この論文から始めて、2つのシステムを完全に異なる方法で比較します。
私は、Mavenの使用方法を学ぼうとしている人を見かけ、Antを例で説明しました。 つまり MavenでAnt'omを行うのに誰もが慣れていることを行う方法を示します。 そして、build.xmlとpom.xmlを比較することでこれを示しています。
しかし、これら2つのファイルを比較することは根本的に間違っています。
ウィキ：
Mavenは、他のApache Antプロジェクトビルダーとは異なり、プロジェクトの命令型ビルドではなく宣言型ビルドを提供します。
つまり、build.xmlでは、他のターゲットを順番に宣言することでターゲットを記述します。これは、コマンドを順番に実行することに非常に似ています。 build.xmlを記述するプロセスは、ビルドスクリプトを記述することに他なりません。 一部のターゲットを他のターゲットに結合します。これにより、明示的にではなく、依存関係の階層を通じて、関数呼び出しの外観が作成されます。 組み立てプロセス全体を完全に設計します。
pom.xmlでは、その自由はありません。 実際、プロジェクトに適切な構造がある場合、Mavenはプロジェクトをどうするかを事前に知っています。 pom.xmlでは、単にプロジェクトを記述します-これはXMLでシリアル化された情報です。 そして、Mavenをうまく使用するには、これらすべてのライフサイクル、フェーズ、その他のことを理解する必要があることがわかります。 Mavenに必要なものとその仕組みを学習し、pom.xmlでプロジェクトを記述する必要があります。 これは通常問題です。 通常、DEVチームでは、このような「自由の制限」は非常に否定的に認識されます。 機能を設計する代わりに、他の人のコードがどのように機能するかを掘り下げ、これらの制限のフレームワークに自分自身を駆り立てる必要があります。 なんで？
まあ、まず、自由の制限自体はそれほど悪くはありません。 このトピックを作成すると、Assembler VS Java holivarに潜り込むことができますが、これは行いません。 SCMで.classpathおよびIDEファイルを表示する頻度を覚えています。 包含物build.xmlのこの複雑さを理解することは時々困難であり、デバッグすることはどれほど困難です。 どのモジュールが以前に構築されているのか、そしてこのjarがそれを戦争に至らなかった理由を理解するのがどれほど難しいか。 また、選別の重量が3Gb程度の場合、アセンブリプロセスの最適化に人的時間を費やします。 また、マネージャーが別の製品との新しい統合を考え出したとき、ローカライズまたはサービスパックの配信の原則を変更したときに、ソリューションの設計にそれらを費やします。 一般的に、多くの頭痛。
ここで、Mavenが私たちに課していることを、自由の制限としてではなく、一種の標準化として認識してみてください。 Mavenを使用して、CIシステム、SCM、課題トラッカー、バックログ、メトリックスなど、どこにでも統合できます。 1つのボタンで製品リリースを行うことができます。 結局、このすべてがこの標準化のおかげで正確に可能になりました（もちろん、Antでこれを行うことは可能ですが、費用はいくらですか？）。 そして、現在90％のケースでアセンブリプロセスを最適化するプロセスは、1つのモジュールを複数の小さなモジュールに分割し、それらを並行してアセンブリできるようにすることです。 開発プロセスの他の参加者との統合も大幅に簡素化され、透明になりました-各チームは独自のMavenリポジトリ（または1つの一般的な企業）を持つことができ、pom.xmlのアーティファクトのバージョンを変更するのはトップマネージャーのみです。
なぜ、彼らはまだAntについてそんなに話しているのですか？ 記事のタイトルで言ったように、一緒に暮らしましょう。 AntとMavenは主に完全に異なるツールであることを理解しましょう。 シンプルで小さなプロジェクトがあり、強力なプロジェクト管理がない場合は、おそらくMavenなしで実行できます。 さらに、あなたが彼に精通していない場合は、勉強に時間を費やす必要があります。 さらに、大きな怪物は通常非常に遅くなります。 このため、それらの多くはまだAntを使用しています。 おそらくマネージャーはMavenに移行する必要性を認識していないか、これは単にサポートされているだけのレガシー製品（またはバージョン）であり、それ以上ではありません。 したがって、Antは需要があり、どこにも行きません。 ただし、Mavenの使用方法を既に知っている場合は、それを使用してください。 これは、将来レーキに乗らないようにするのに役立ちます。 それでも、JavaとAntは基本的に同じ世代であり、Mavenはずっと後に作成されました-過去数年で得られたすべての経験を取り入れています。
便利なリンク：
Ivyは自分をMavenと比較します： ant.apache.org/ivy/m2comparison.html
codehausからの比較： docs.codehaus.org/display/MAVEN/Feature+Comparisons
別の興味深い視点： xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html