なぜmavenなのか？利点は何ですか？
Antと言えば、mavenを使用する主な利点は何ですか？それは有用なツールというよりも厄介なようです。プレーンなEclipse Java EE（m2Eclipseなし）およびTomcatを備えたMaven 2を使用します。
Mavenの支持者は、
Mavenを使用すると、パッケージの依存関係を簡単に取得できます
Mavenは、標準のディレクトリ構造を強制します
私の経験では
パッケージの依存関係を把握することは、それほど難しくありません。とにかくめったにやらない。おそらく、プロジェクトのセットアップ中に1回、アップグレード中にもう少しです。 mavenを使用すると、依存関係の不一致、不適切に記述されたpoms、およびとにかくパッケージの除外を修正することになります。
FIX-COMPILE-DEPLOY-DEBUGサイクルが遅いため、生産性が低下します。これが私の主な不満です。変更を加えると、mavenビルドが開始され、デプロイされるのを待つ必要があります。ホット展開は一切ありません。
それとも私は間違っていますか？正しい方向を教えてください、私はすべての耳です。
パッケージの依存関係を把握することは、それほど難しくありません。とにかくめったにやらない。おそらく、プロジェクトのセットアップ中に1回、アップグレード中にもう少し。 Mavenを使用すると、依存関係の不一致、不適切に記述されたPOM、およびとにかくパッケージの除外を修正することになります。
それほど難しいことではありません...おもちゃのプロジェクトには。しかし、私が取り組んでいるプロジェクトには多くの、本当に多くのプロジェクトがあり、それらを一時的に取得し、標準化された命名スキームを持っていることを非常にうれしく思います。これらすべてを手動で手動で管理するのは悪夢です。
もちろん、依存関係の収束に取り組む必要がある場合もあります。しかし、考え直してください。これはMavenに固有のものではなく、依存関係を使用するすべてのシステムに固有のものです（ここでは一般的にJava依存関係について説明しています）。
したがって、Antでは、same作業を行う必要があります。ただし、すべてを手動で行う必要があります。プロジェクトAの一部のバージョンとその依存関係を取得し、一部を取得するプロジェクトBのバージョンとその依存関係、使用している正確なバージョンの把握、重複しないことの確認、互換性がないことの確認など。地獄へようこそ。
一方、Mavenは依存関係管理をサポートし、それらを一時的に取得し、依存関係管理に固有の複雑さを管理するために必要なツールを提供します：依存関係ツリーを分析し、推移的な依存関係で使用されるバージョンを制御し、それらの一部ifを除外し、モジュール間の収束を制御することができます。魔法はありません。しかし、少なくともあなたにはサポートがあります。
また、依存関係管理はMavenが提供するもののごく一部にすぎないことを忘れないでください（Mavenとうまく統合する他のツール、たとえば Sonar ）には言及していません）.
FIX-COMPILE-DEPLOY-DEBUGサイクルが遅いため、生産性が低下します。これが私の主な不満です。変更を加えると、mavenビルドが開始され、デプロイされるのを待つ必要があります。ホット展開は一切ありません。
まず、なぜこのようにMavenを使用するのですか？しません。 IDEを使用して、テストを作成し、テストが合格するまでコードを作成し、リファクタリング、デプロイ、ホットデプロイを行い、完了したら、コミットする前に、ローカルMavenビルドを実行して、ビルドします。
第二に、Antを使用することで状況が改善されるかどうかわかりません。私の経験では、バイナリ依存関係を使用したモジュラーMavenビルドは、典型的なモノリシックAntビルドよりもビルド時間を短縮します。とにかく、 Maven Shell をご覧ください。Maven環境を（再）使用する準備ができています（ちなみに素晴らしいです）。
最後に、残念ながら、生産性を低下させているのはMavenではなく、ツールを誤用しているということです。そして、あなたがそれに満足していないなら、まあ、私が言うことができる、それを使用しないでください。個人的には、2003年からMavenを使用していますが、振り返ることはありません。
Mavenは、Antのようなビルドツールだけでなく、完全なプロジェクト開発ツールと考えることができます。 Eclipse IDE with maven plugin を使用して、すべての問題を修正する必要があります。
Mavenを使用する利点 ページから引用した、Mavenのいくつかの利点を次に示します。
ヘニング
- プロジェクトの迅速なセットアップ、複雑なbuild.xmlファイルは不要、POMのみ
- プロジェクトのすべての開発者は、集中化されたPOMにより、同じjar依存関係を使用します。
- プロジェクトの多数のレポートとメトリックを「無料で」取得する
- jarは中央の場所からプルできるため、ソース配布のサイズを縮小します。
エマニュエル・ヴェニス
- 多くの目標が利用可能であるため、ANTに反して特定のビルドプロセスパーツを開発する必要はありません。ビルドプロセスで既存のANTタスクをantrunプラグインで再利用できます。
ジェシー・マッコネル
- コードのモジュール設計を促進します。複数のプロジェクトを簡単に管理できるようにすることで、デザインを複数の論理的なパーツにレイアウトし、pomファイルで依存関係の追跡を使用してこれらのパーツをまとめることができます。
- コードのモジュール設計を実施します。モジュラーコードにlipserviceを支払うのは簡単ですが、コードが個別のコンパイルプロジェクトにある場合、依存関係管理で明確に許可しない限り、コードのモジュール間で参照を相互受益することは不可能です。今すぐこれを行い、後で実装を修正してください。
- 依存関係管理が明確に宣言されています。依存関係管理メカニズムを使用すると、jarバージョン管理を台無しにしようとする必要があります...「このベンダーjarのどのバージョンがこれですか？」という古典的な問題はありません。そして、既存のプロジェクトでそれを設定すると、物事を稼働させるためにリポジトリに「不明な」バージョンを作成することを余儀なくされたときに存在する場合、既存の混乱の頂点を切り裂きます... ABC.jarの実際のバージョン。
- 強力な型のライフサイクルがあり、ビルドの開始から終了までソフトウェアシステムが通過する強力な定義済みのライフサイクルがあります。ユーザーは、自分のライフサイクルを組み合わせることなく、システムをライフサイクルに合わせて組み合わせることができます。これには、あるプロジェクトから別のプロジェクトに移動し、ソフトウェア構築に関して同じ語彙を使用して話すことができるという追加の利点があります
ビンセント・マッソル
- より大きな勢い：Antは今やレガシーであり、急速に前進していません。 Mavenは急速に前進しており、Mavenの周辺には価値の高いツールが多数ある可能性があります（CI、ダッシュボードプロジェクト、IDE統合など）。
小さなプロジェクトの依存関係を理解することは難しくありません。しかし、数百の依存関係を持つ依存関係ツリーの処理を開始すると、物事は簡単に手に負えなくなる可能性があります。 （私はここでの経験から話しています...）
もう1つのポイントは、インクリメンタルコンパイルとMavenサポート（Eclipse + m2Eclipseなど）でIDEを使用する場合、編集/コンパイル/ホットデプロイとテストをセットアップできるはずです。
私は個人的にこれをしません。なぜなら、過去の悪い経験のために、この開発モードに不信感を抱くようになったからです（Maven以前）。おそらく誰かが、これがEclipse + m2Eclipseで実際に機能するかどうかについてコメントすることができます。
アリに対するMavenの利点はかなりあります。ここで要約します。
設定より規約
Mavenは、プロジェクトのレイアウトと起動に独特のアプローチを使用しているため、プロジェクトに簡単にジャンプできます。通常、プロジェクトのアーティファクトを取得するには、checkountコマンドとmavenコマンドのみが必要です。
プロジェクトのモジュール化
プロジェクトの規則では、開発者がプロジェクトをモジュール化することを提案しています（または、より良いことを強制します）。モノリシックプロジェクトの代わりに、プロジェクトをより小さなサブコンポーネントに分割せざるを得ないことがよくあります。これにより、プロジェクト構造全体のデバッグと管理が容易になります。
依存関係管理とプロジェクトライフサイクル
全体的に、優れたSCM構成と内部リポジトリにより、依存関係の管理は非常に簡単です。また、コンポーネントのバージョン、リリース管理など、プロジェクトライフサイクルの観点から考える必要があります。アリの何かよりも少し複雑ですが、これもプロジェクトの品質の向上です。
mavenの何が問題になっていますか？
Mavenは簡単ではありません。ビルドサイクル（何がいつ行われるか）は、POM内ではそれほど明確ではありません。また、コンポーネントの品質と公開リポジトリの依存関係の欠落にいくつかの問題が発生します。
最良のアプローチ（私にとって）は、依存関係をキャッシュ（および保持）するための内部リポジトリを持ち、コンポーネントのリリース管理に適用することです。本の中のサンプルプロジェクトよりも大きなプロジェクトの場合、mavenに感謝します
Mavenは、実際に学習するのにかなりの時間を費やし、その決定を一度だけ行うので、実際に必要なツールの1つです決定学習中にあらゆる種類の疑念をスキップすることができます（like itおよびwantを使用するため）！
強力な規則は多くの場所で役立ちます（Mavenプロジェクトで素晴らしいことができるHudsonなど）が、最初は見にくいかもしれません。
編集：2016年現在、Mavenは3つの主要なIDEすべてがすぐにソースを使用できる唯一のJavaビルドツールです。つまり、mavenを使用すると、ビルドがIDEに依存しなくなります。これにより、たとえば通常Eclipseで作業している場合でもNetbeansプロファイリングを使用する
Mavenは、標準の規則と慣行を採用して開発サイクルを加速すると同時に、より高い成功率を達成できるようにすることで、ビルドプロセスにメリットをもたらします。 Mavenが開発プロセスでどのように役立つかについての詳細は、Mavenを使用する利点を参照してください。
Mavenは、POM（プロジェクトオブジェクトモデル）に基づく強力なプロジェクト管理ツールです。プロジェクトのビルド、依存関係、およびドキュメントに使用されます。 ANTのようなビルドプロセスを簡素化します。しかし、ANTよりも高度です。 Mavenは、ビルド、ドキュメント、修復、SCM、リリース、配布の管理に役立ちます。 -mavenリポジトリは、pom.xmlファイルを含むパッケージ化されたJARファイルのディレクトリです。 Mavenはリポジトリ内の依存関係を検索します。
ポイント2に出くわしたことはありませんか？これが何らかの形で展開に影響を与えると考える理由を説明できますか。 Mavenを使用すると、特定の層のバグのホットフィックスを実際に可能にし、たとえばプロジェクトの残りの部分からAPIを独立して開発できるモジュール化された方法でプロジェクトを構築できます。
すべてを1つのモジュールに詰め込もうとしている可能性があります。その場合、問題はまったくのMavenではなく、使用方法にあります。
これはコメントであるはずでしたが、コメントの長さに収まっていなかったため、回答として投稿しました。
他の回答に記載されているすべての利点は、mavenを使用するよりも簡単な方法で達成できます。たとえば、プロジェクトを初めて使用する場合、jarをダウンロードしてlibフォルダーにコピーするよりも、プロジェクトアーキテクチャの作成、コンポーネントの結合、コーディングに時間がかかります。ドメインの経験がある場合は、どのライブラリを使用してプロジェクトを開始するかをすでに知っています。特に「依存関係管理」を自動的に行っているときに多くの問題が発生する場合、Mavenを使用する利点はありません。
私はMavenの中間レベルの知識しかありませんが、Mavenを使用せずに大規模なプロジェクト（ERPなど）を行ったことがあります。