ビルダー、Gradle、またはMaven 3を待ちますか？
私はいつもMaven 2と格闘することに本当にうんざりしています。ビルドツールが邪魔にならないようにしてください。最近、私はBuildrとGradleを見てきました。 Maven 3はいくつかの問題を解決しているようです。それで、私は今何のために行くべきですか？ビルダー？ Gradle？または、Maven 3を1年待ちますか？
ビルドシステムは魔法の弾丸ではありません。 Mavenは私が引き起こした問題よりも多くの問題を解決できると思いますが、欠点を克服するためにプラグインを書くのは非常に快適です。また、何百ものプロジェクトに対処しているため、Mavenの継承と依存関係の処理は私にとって非常に役立ちます。
参照SO少しすると、BuildrとGradleの両方に問題があることもわかります（AntとIvyでも同じです）、一般に、ある問題のセットを別の問題と交換し、それを見つける場合最も痛みが少ない。
Mavenについて気になっていることはありますか、それとも一般的なかゆみですか？特定の問題である場合は、 JiraでのMaven 3の問題 を見る価値があります。問題に対処しない場合は、問題を提起できます。
Maven 3にはあまり期待しません。Mavenのビルドツールの血統の裏にいる人々は、プロジェクトビルドは均質である、つまりすべてのビルドの問題は根本的に同じ問題に根付くという前提を常に守ってきました。この世界観は、相反する見解に直面してもかなり一貫して保持することができますが、コストがかかります。 Mavenにスクリプティングロジックが存在しない（「スクリプトを作成したいとき、何か間違ったことをしていることを知っている」）、面倒なプラグインAPI（「普通のMavenユーザーはプラグインを書きたくない」）および中央リポジトリ（「weすべてが同じ依存関係を持っている」）はすべて、この包括的な仮定の証です。
現実の世界では、人々はさまざまな理由でソフトウェアを構築するため、ビルドの問題は異質です。それらはすべて、私たち全員がたまに「穴を開ける」ように、独自の問題を解決するために「開発」します。抽象化のレベルに関係なく、任意のビルドの問題を比較するときは常に類似点が見つかります。これらの類似性の復活と相違点の非難が、Mavenのデザインの没落であり、Mavenが非常に高い評価を得る理由です。基本的に、MavenはOutlookで権威主義的かつユートピア的です。
PS：Mavenには、convention-over-configurationやリポジトリを使用するというアイデアのような優れた機能があります（このアイデアのMaven実装は面倒です）。
ここではMavenを使用しますが、単純なプロジェクトの外に出ると、pom.xmlはますます複雑になり始めます。あなたは、あなたが望むことをするようにあなたのpomをどのように設定するのか、そして様々な問題を回避する方法の解決に多くの時間を費やし始めます。
私が本当に得たのは、私たちが作っている耳でした。そのearファイルには複数の戦争があり、通常Mavenは戦争にライブラリを貼り付けます。ただし、戦争のサイズを小さくし、すべてのjarファイルを同じ状態に保つために、戦争間で共有されるjarファイルを耳のlibディレクトリに入れたいと考えました。
残念ながら、Mavenはこれをうまく処理できません。戦争の各pomに対してこれを手動で構成し、これらの依存関係をすべて耳のpomに追加する必要がありました。
別のプロジェクトには、HTMLベースのヘルプファイルがあります。ヘルプを作成する人々は、Microsoft Wordでそれらを作成し、プログラムを使用してHTMLに変換します。単一の文字の変更は、数百のファイル全体にわたって反響する可能性があります。
この問題を回避するために、ヘルプシステムは単一のzipファイルとしてソースリポジトリに保存されます。ドキュメントチームがヘルプファイルの新しいセットを作成するとき、彼らはそれを圧縮し、リポジトリにあるものを置き換えます。
したがって、私のビルドの一部は、このファイルを解凍し、戦争に配置することです。 Antで簡単に実行できます。Mavenで完全なプラグインなしでは処理できない問題を処理するAntコードを記述できるAntrunプラグインを使用しない限り、Mavenで実行できません。
Mavenが何をしているのかはわかりますが、理論は現実よりも先を行っています。私が見つけたのは、IvyとAntが、pomsの作成と保守のすべての問題なしに、Mavenが行う依存関係チェックのほとんどを実行できることです。
まだMavenを使用していない場合は、まずIvyでAntを試してください。それから、Maven 3が出てきたら、それを試してください。 Maven 1からMaven 2への移行を覚えています。これらは互いに完全に互換性がなく、Maven 1を使用して学んだことは時代遅れでした。 Maven 2でプロジェクトを学習してやり直すと、Maven 3のすべてを突然やり直すことになります。
maven 3.xはすでにIDEに組み込まれています（少なくともnetbeansでは、詳細については このリンク を確認してください）。 NetBeansを使用してMavenプロジェクトを構築するだけで、maven 3.xで今日プレイできます。
もう1つの素晴らしいニュースは、MavenがEJB/WSをIDEプロジェクト（少なくともnetbeansでもう一度）に統合することでより多くの 'エンタープライズ'サポートを得たことです。
したがって、本番ビルドではmaven 2.xを使い、開発ではmaven 3.xを使用します。
Maven 2と3は、さまざまなプロジェクトで完璧に機能しています。私は現在、特にEclipse Mavenプラグインと組み合わせて非常にうまく機能するMaven 3 alpha 7を使用しています。
MavenはAntとシームレスに統合されます（両方向）。私の現在のプロジェクトでは、複雑な統合テストを実行するために、MavenをAntから複数回呼び出します。同様に、MavenのAntRunプラグイン経由でAntを使用し、独自のMavenプラグインも作成しました。ちなみに、これはほんの数分であり、要約すると注釈付きのPojoを書くことになります。
多くの開発者がルールや規則を好まないため、Mavenには多くの欠点があります。簡単に言えば、Mavenの使用を強制する人はいません。究極の自由が必要な場合-どうしても-参加するプロジェクトごとに独自のビルドプロセスを書き直してください。ただし、すべてのプロジェクトでカスタムビルドプロセスを使用して車輪を再発明するのではなく、ソフトウェアを作成する場合は、Mavenを使用してください。
コードを適切に維持し、適切に定義されたモジュールに分割しておくと、ビルドシステム間での移植は軽微な問題になります。
今のところ、maven-2はプロジェクトの中間2/3に適しています。本当にシンプルなため、アリはまだ大丈夫です。本当に複雑な場合、maven-2と他のツール（antrunなど）のハイブリッドは避けられません。
Maven-2で問題が発生している理由がわかりません。
Antやbuildrとは異なり、スクリプトではなく、ビルドプロセスを記述するためのツールです。複雑なビルド、複数の動的な部分、ネストされた依存関係、および/または一時的な依存関係を持つビルドは、説明が難しいためビルドが困難です。
ラティスを与える https://github.com/hackingspirit/Lattice 試してみてください。私は著者です。ここにスクープがあります：
Latticeでは、ビルドファイルはXMLではなくPython言語で書かれています。利点は、Pythonでサポートされる読みやすさと強力な命令型ビルドスクリプトです。マルチモジュールプロジェクトの場合。ラティスはトポロジカルソートを使用して、各モジュールを構築する正しい順序を決定します。また、モジュールのコンパイルを並列化する方法を決定するために、ラティスがモジュールの依存関係を分析することも計画されています。ラティスのソースコードは非常に無駄がなく、現在は約500行のPythonソースコードで構成されています。
Mavenについて不満を言う人は、利用可能なプラグインの調査に少し余分な時間を費やすべきだと思います。 Mavenは厳格であり、カスタムビルドロジックの使用を困難にし、ビルドプロセスをきめ細かく制御することを困難にしているというコメントに応えて、MavenのAntプラグインを調べることをお勧めします（実際にはいくつかありますが、ここに1つあります） ： http://maven.Apache.org/plugins/maven-antrun-plugin ）。私は長年にわたってMavenビルドをカスタマイズして大きな成功を収めてきました。基本的に、Mavenビルドの一部として任意のAntコマンドを実行でき、Antを使用してほとんど何でも実行できます;）
Ivyを使用したAntは、Mavenと同じ依存関係管理を行います（実際、同じURLリポジトリを含むMavenの依存関係管理インフラストラクチャ全体を使用します）が、すべてのPOM構成の混乱はありません。
Ivyを使用したAntは、Mavenを実際に使用したくない人のための依存関係の問題を処理する方法かもしれません。 Mavenが解決すると考えられていたものの90％を解決します。