AntやMavenの代わりにGradleを使うのはなぜですか？
Javaをターゲットにした別のビルドツールは本当に私に何をもたらしますか？
もしあなたがGradleを他のツールの上で使うのなら、なぜでしょうか？
私は怒りの中で Gradle を使っていません（これまでのところ単なるおもちゃのプロジェクト）そのGradleは玩具プロジェクトです - コメントを見てください]、しかしそれを使うことを考える理由はAntとMavenの欲求不満のためだろうと私は言います。
私の経験ではAntはしばしば書き込み専用です（そう、私は 美しくモジュール化されたエレガントなビルド を書くことは可能ですが、ほとんどの人はそうではありません）。自明ではないプロジェクトでは、それは気が遠くなるようになり、複雑なビルドが本当に移植性のあるものになるように細心の注意を払います。その必須の性質は、ビルド間で構成を複製することにつながります（ただし、ここでマクロを使用することもできます）。
Mavenは反対のアプローチを取り、Mavenのライフサイクルと完全に統合することを期待しています。 MavenがAntにある自由の多くを取り除くので、経験豊富なAntユーザーは特に不快に感じます。例えば、 Sonatypeブログ があります。これはMavenの批判の多くとその回答を列挙しています。
Mavenプラグインメカニズムは非常に強力なビルド設定を可能にし、継承モデルはあなたがあなたのビルド設定をカプセル化しているエンタープライズ全体のための親POMの小さなセットを定義することができることを意味します。 Maven 3はこれに対処すると約束していますが、Mavenの設定は非常に冗長です。もしあなたが "Mavenのやり方ではない"ということをしたいのなら、プラグインを書くかハッキーなAnt統合を使わなければなりません。注意私はMavenプラグインを書くのが好きだと思いますが、多くの人が関与する努力に反対することを認めています。
GradleはAntとMavenの間のスイートスポットを打つことを約束します。依存関係の解決には、 Ivy のアプローチを使用します。これは設定上の規約を可能にしますが、一級市民としてのAntタスクも含みます。それはまた賢明にあなたが既存のMaven/Ivyリポジトリを使うことを可能にします。
ですから、Ant/Mavenの問題点のいずれかにぶつかって動けなくなったら、おそらくGradleを試してみる価値があります。ただし、私の考えでは、既知の問題を未知の問題と交換するのではないかと思われます。プリンの証明は食べ物にありますが、製品がもう少し成熟し、他の人がキンクを解決するまで判断を保留します（理由からブリードエッジと呼びます）。私はまだ私のおもちゃのプロジェクトでそれを使っているつもりです、それはオプションを知っていることは常に良いことです。
Gradleは、Antよりもはるかに優れたスイスのアーミーナイフです - しかし、マルチプロジェクトビルドに特に焦点を当てています。
まず第一に、Gradleは依存性プログラミングツールです。これはプログラミングツールでもあることを意味します。 Gradleを使えば、あなたの設定で任意のランダムなタスクを実行することができ、Gradleは宣言されたすべての依存関係が適切かつタイムリーに実行されることを確認します。あなたのコードはどんな種類のレイアウト（ツリー、フラット、散在、...）で多くのディレクトリにまたがることができます。
Gradleには評価と実行という2つの異なるフェーズがあります。基本的に、評価中にGradleはそれが探すべきディレクトリでビルドスクリプトを探して評価します。実行中、Gradleはタスクの相互依存性を考慮して評価中にロードされたタスクを実行します。
これらの依存関係プログラミング機能に加えて、GradleはApache Ivyとの統合によってプロジェクトとJARの依存関係機能を追加します。ご存じのように、IvyはMavenよりもはるかに強力で、あまり説得力のない依存関係管理ツールです。
Gradleはプロジェクト間およびプロジェクトとJAR間の依存関係を検出します。 Gradleは、iBiblioやあなた自身のリポジトリのようなMavenリポジトリ（ダウンロードとアップロード）で動作しますが、あなたが持っているかもしれない他の種類のリポジトリインフラストラクチャもサポートします。
マルチプロジェクトビルドでは、Gradleはビルドの構造とアーキテクチャに適応可能であり、かつ適応しています。 Mavenで必要とされるように、あなたの構造やアーキテクチャをあなたのビルドツールに適応させる必要はありません。
Gradleはあなたの邪魔にならないように一生懸命努力しています。コンベンションは良いですが柔軟性もそうです。 GradleはMavenよりも多くの機能を提供しますが、多くの場合最も重要なことにGradleはMavenから離れた苦痛のない移行パスを提供します。
これは少し物議をかもすかもしれませんが、Gradleはそれが本格的なプログラミング言語であるという事実を隠しません。
Ant + ant-contribは本質的には誰も実際にプログラミングしたくないチューリングの完全なプログラミング言語です。
Mavenは完全に宣言的であることを試み、ロジックが必要な場合はプラグインを書いてコンパイルすることを強制するという反対のアプローチを取ろうとします。それはまた完全に柔軟性のないプロジェクトモデルを課します。 Gradleはこれらすべてのツールの最高のものを組み合わせたものです。
- これは、コンベンションオーバーコンフィギュレーション（ala Maven）に従いますが、必要な範囲内でのみです。
- Antのように柔軟なカスタムタスクを書くことができます。
- AntとMavenの両方に勝るマルチモジュールプロジェクトサポートを提供します。
- それは80％のことを容易にし、20％のことを可能にするDSLを持っています（80％を容易にする他のビルドツールとは異なり、10％を可能にし、10％を事実上不可能にします）。
Gradleは私がまだ使っていない最も構成可能で柔軟な構築ツールです。 DSLや設定などの概念を学ぶためには、いくらかの投資が必要ですが、ナンセンスで完全に設定可能なJVMビルドツールが必要な場合は、それを克服するのは困難です。
GradleはAntとMavenの両方をうまく組み合わせて、両方のフレームワークの長所を活用しています。 Antからの柔軟性とMavenによる設定、依存関係管理、プラグインに関する規約。
ですから、もしあなたがmavenのように標準のJavaビルドをしたいのであれば、テストタスクはいくつかのカスタムステップをしなければなりませんそれは以下のようになるでしょう。
build.gradle：
apply plugin:'Java'
task test{
doFirst{
ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
}
doLast{
...
}
}
それに加えて、それはant/mavenのxmlよりもはるかに多くの表現力を与えるgroovy構文を使用します。
それはAntのスーパーセットです - あなたはより良い、グルーヴィーな構文を使ってすべてのAntタスクをつないで使うことができます。
ant.copy(file:'a.txt', toDir:"xyz")
または
ant.with{
delete "x.txt"
mkdir "abc"
copy file:"a.txt", toDir: "abc"
}
私たちはGradleを使い、MavenとAntよりもそれを選びました。 Antは私たちに完全な柔軟性を与え、IvyはMavenよりも優れた依存関係管理を提供しますが、マルチプロジェクトビルドのための素晴らしいサポートはありません。マルチプロジェクトビルドをサポートするために、結局たくさんのコーディングをすることになります。コンベンションによるビルドもあるのはいいことで、ビルドスクリプトをより簡潔にします。 Mavenを使えば、慣習的にビルドするのが難しくなり、ビルドプロセスをカスタマイズするのはハックとなります。また、Mavenは成果物を公開するすべてのプロジェクトを宣伝します。プロジェクトをサブプロジェクトに分割している場合もありますが、すべてのサブプロジェクトを一緒にビルドしてバージョン管理する必要があります。 Mavenが設計されたものではありません。
Gradleを使えば、Antの柔軟性を持ち、Mavenの慣習に従って構築することができます。たとえば、従来のビルドライフサイクルを自分のタスクで拡張することは簡単です。あなたがしたくない場合は、あなたは慣習を使用することを強制されていません。 Groovyは、XMLよりもコードがはるかに優れています。 Gradleでは、それぞれの成果物をリポジトリに公開する必要なしに、ローカルファイルシステム上のプロジェクト間の依存関係を定義できます。最後に、GradleはIvyを使用しているため、優れた依存関係管理があります。私にとってこれまでの唯一の本当の欠点は、成熟したEclipse統合の欠如ですが、Mavenのオプションはそれほど良くありません。
これは私の答えではありませんが、確かに私と共鳴します。それは2012年10月からの ThoughtWorksの技術レーダーからです ：
AntやMavenのようなXMLベースのビルドツールでは、2つのことが疲労を引き起こしています。構文の問題は生成を通じて対処することができますが、プラグインアーキテクチャでは、プロジェクトが複雑になるにつれてビルドツールが適切に成長する能力が著しく制限されます。我々はプラグインが間違った抽象化レベルであると感じ、そしてよりきめの細かい抽象化とより柔軟な長期を提供するので、代わりにGradleやRakeのような言語ベースのツールを好むようになりました。
Gradleはその楽しみをソフトウェアの構築/組み立てに戻しました。私は私のキャリア全体をソフトウェアで構築するためにantを使っていましたが、開発作業の実際の "buildit"部分は常に必要な悪と考えてきました。数か月前、私たちの会社はバイナリレポジトリ（vcsにjarをチェックインすること）を使わないことにうんざりして、私はこれを調査する仕事を与えられました。それがantの上にボルトで固定されることができたのでアイビーから始めました、私が望んだように私の造られた遺物が公表されることに多くの運がありませんでした。私はMavenに行き、xmlをハックし、いくつかの単純なヘルパーライブラリのために素晴らしい働きをしました、しかし私は展開の準備ができているアプリケーションを束ねようとしている深刻な問題に遭遇しました。グーグルでプラグインを読みフォーラムを読むのにかなり手間をかけ、私が使うのに苦労した様々なプラグインのために何兆ものサポートjarをダウンロードするのをやめました。最後に私はgradleに行きました（この時点でかなり苦くなって、そして「これは難しいことではないはずです！」
しかし、初日から私の気分は良くなり始めました。私はどこかに着いていました。私の最初のantモジュールを移行するのに2時間かかると思ったのですが、ビルドファイルは基本的に何もしていませんでした。 1画面で簡単に取り付けられます。大きな "すごい"は次のとおりです。xmlでbuildスクリプト、それはどれほどばかげている？ 1つの依存関係を宣言すると1行かかるのは私にとって非常に魅力的です - > 1つのページで特定のプロジェクトのすべての依存関係を簡単に見ることができます。それ以来、私はこれまでずっと直面してきたすべての問題に対してシンプルで洗練された解決策があります。これらが理由だと思います。
- groovyはJava開発者にとって非常に直感的です。
- ドキュメンテーションは素晴らしいものから素晴らしいものまで
- 柔軟性は無限大です
今私は私たちのビルドプロセスに追加するために新しい機能を考えようとしている私の日々を過ごします。それはどのくらい病気ですか？
ネイティブビルドの管理もはるかに簡単です。 AntとMavenは事実上Javaのみです。 Mavenにはネイティブプロジェクトを処理しようとするプラグインがいくつかありますが、効果的な仕事はしません。ネイティブプロジェクトをコンパイルするAntタスクは書くことができますが、それらは複雑すぎて扱いにくいものです。
私たちはJNIや他の多くのネイティブビットを使ってJavaを行います。 GradleはAntの混乱をかなり単純化しました。ネイティブプロジェクトに依存関係管理を導入し始めたとき、それは面倒でした。私たちはMavenにそれをやらせました、しかし同等のGradleコードはMavenで必要とされたもののほんの一部でした、そして人々はMavenの教祖にならずにそれを読んで理解することができました。
私はEd Staubに部分的に同意します。 Gradleは間違いなくmavenと比較して強力であり、長期にわたってより高い柔軟性を提供します。
Mavenからgradleに移動するための評価を実行した後、我々はgradleで遭遇した2つの問題のためにmaven自身に固執することに決めました（速度はmavenより遅いです、プロキシは働いていませんでした）。