AntまたはMavenの代わりにGradleを使用する理由 [閉まっている]

Javaをターゲットにした別のビルドツールで本当に何ができるのですか？

他のツールでGradleを使用するのはなぜですか？

私は自分自身でGradleを怒りで使用していません（これまでのところ、おもちゃのプロジェクトだけです）[著者は、Gradleはおもちゃのプロジェクトでのみ使用しており、Gradleはおもちゃのプロジェクトではありません。コメントを参照してください]と言いますが、それを使用することを検討する理由は、AntとMavenの不満のためです。

私の経験では、Antは書き込み専用であることがよくあります（美しくモジュール化されたエレガントなビルドを作成することは可能ですが、ほとんどの人はそうではありません）。自明ではないプロジェクトの場合、それは心が痛むものになり、複雑なビルドが本当に移植可能であることを保証するために細心の注意を払います。その必須の性質により、ビルド間で構成が複製される可能性があります（ただし、マクロが役立つ場合があります）。

Mavenは逆のアプローチをとり、Mavenライフサイクルと完全に統合することを期待しています。経験豊富なAntユーザーは、MavenがAntに持っている多くの自由を取り除いているので、これは特に不愉快です。たとえば、Mavenの批判とその回答の多くを列挙したSonatypeブログがあります。

Mavenプラグインメカニズムは非常に強力なビルド構成を可能にします。継承モデルは、エンタープライズ全体のビルド構成をカプセル化する親POMの小さなセットを定義でき、個々のプロジェクトがそれらの構成を継承して軽量化できることを意味します。Mavenの設定は非常に冗長です（ただし、Maven 3はこれに対処することを約束します）。「Mavenの方法ではない」ことを行う場合は、プラグインを作成するか、Hacky 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の1つまたは独自のリポジトリのようなMavenリポジトリ（ダウンロードおよびアップロード）で動作しますが、その他の種類のリポジトリインフラストラクチャもサポートします。

マルチプロジェクトビルドでは、Gradleは適応可能であり、ビルドの構造とアーキテクチャに適応します。Mavenで必要となるように、構造やアーキテクチャをビルドツールに適合させる必要はありません。

Gradleは邪魔にならないように一生懸命努力しますが、Mavenが行うことはほとんどありません。慣習は順調ですが、柔軟性もあります。GradleはMavenよりもはるかに多くの機能を提供しますが、最も重要なのは、多くの場合、GradleはMavenからの簡単な移行パスを提供することです。

これは少し物議をかもすかもしれませんが、Gradleは完全なプログラミング言語であるという事実を隠しています。

Ant + ant-contribは、本質的には誰もプログラミングしたくない、完全なプログラミング言語です。

Mavenは、完全に宣言的であることを試み、ロジックが必要な場合はプラグインを作成してコンパイルするという反対のアプローチを取ろうとします。また、完全に柔軟性に欠けるプロジェクトモデルを課します。Gradleは、これらすべてのツールの最高のものを組み合わせています。

• これは、convention-over-configuration（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タスクはすべて、Gradleでより良いグルーヴィーな構文で使用できます。

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つのことが疲労を引き起こしています。1つは、怒りの多い先のとがった中括弧と、プラグインアーキテクチャの粗さです。構文の問題は生成を通じて対処できますが、プラグインアーキテクチャでは、プロジェクトが複雑になるにつれてビルドツールが適切に成長する能力が大幅に制限されます。プラグインは抽象化のレベルが間違っていると感じており、代わりにGradleやRakeなどの言語ベースのツールを好んでいます。

Gradleは、ソフトウェアの作成/組み立てに楽しさを取り戻しました。私はantを使用して自分のキャリア全体でソフトウェアをビルドし、開発作業の実際の「buildit」部分は必要悪であると常に考えていました。数か月前、当社はバイナリレポ（別名jarをvcsにチェックイン）を使用しないことにうんざりしており、私はこれを調査するタスクを与えられました。antの上にボルトで固定できるため、ivyから始めましたが、私の作成したアーティファクトを望みどおりに公開するのにあまり運がありませんでした。私はmavenに行ってxmlをハックし、いくつかの単純なヘルパーライブラリに素晴らしく働きましたが、デプロイ可能なアプリケーションをバンドルしようとして深刻な問題に遭遇しました。プラグインやフォーラムを読んだり、使用に苦労したさまざまなプラグイン用の何兆ものサポートjarをダウンロードしたりするのにかなり時間がかかりました。

しかし、初日から気分は良くなり始めました。私はどこかに着いていた。最初のantモジュールとビルドファイルを移行するのに2時間ほどかかったので、基本的には何もありませんでした。1つの画面に簡単に取り付けられます。大きな "すごい"は次のとおりです：xmlでスクリプトをビルドします。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自体を使用することにしました。