324

Javaを対象とした別のビルドツールで実際に何が得られますか？

別のツールでGradleを使用する場合、なぜですか？

4

9 に答える 9

248

私は自分自身を怒らせてGradleを使用していません（これまでのところおもちゃのプロジェクトだけです） [著者は、Gradleがおもちゃのプロジェクトであるということではなく、これまでおもちゃのプロジェクトだけでGradleを使用したことを意味します-コメントを参照してください]、しかし私はそれを言うでしょうそれを使用することを検討する理由は、AntとMavenのフラストレーションのためです。

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

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

Mavenプラグインメカニズムにより、非常に強力なビルド構成が可能になります。継承モデルは、企業全体のビルド構成をカプセル化する親POMの小さなセットを定義でき、個々のプロジェクトがそれらの構成を継承して軽量化できることを意味します。Mavenの構成は非常に冗長であり（Maven 3はこれに対処することを約束していますが）、「Mavenの方法ではない」ことを行う場合は、プラグインを作成するか、ハッキーなAnt統合を使用する必要があります。私はたまたまMavenプラグインを書くのが好きですが、多くの人がそれに伴う努力に反対することを理解しています。

Gradleは、AntとMavenの間のスイートスポットに到達することを約束します。依存関係の解決にはIvyのアプローチを使用します。設定より規約が可能ですが、第一級市民としてのAntタスクも含まれています。また、既存のMaven/Ivyリポジトリを賢く使用することもできます。

したがって、Ant / Mavenの問題点のいずれかにぶつかって行き詰まった場合は、Gradleを試してみる価値がありますが、私の意見では、既知の問題を未知の問題と交換するだけではないかどうかは不明です。プリンの証拠は食べることですが、製品がもう少し成熟し、他の人がねじれを解消するまで判断を保留します（彼らはそれを理由で最先端と呼んでいます）。私はまだおもちゃのプロジェクトでそれを使用しますが、オプションを知っていることは常に良いことです。

于 2009-07-22T14:11:52.050 に答える
79

Gradleは多くの目的に使用できます-Antよりもはるかに優れたスイスアーミーナイフです-しかし、特にマルチプロジェクトビルドに焦点を当てています。

まず第一に、Gradleは依存関係プログラミングツールであり、これはプログラミングツールでもあることを意味します。Gradleを使用すると、セットアップで任意のランダムタスクを実行でき、Gradleは、宣言されたすべての依存関係が適切かつタイムリーに実行されることを確認します。コードは、あらゆる種類のレイアウト（ツリー、フラット、分散など）の多くのディレクトリに分散できます。

Gradleには、評価と実行という2つの異なるフェーズがあります。基本的に、評価中にGradleは、検索するはずのディレクトリでビルドスクリプトを検索して評価します。実行中、Gradleは、タスクの相互依存性を考慮して、評価中にロードされたタスクを実行します。

これらの依存関係プログラミング機能に加えて、GradleはApacheIvyとの統合によりプロジェクトとJARの依存関係機能を追加します。ご存知のように、Ivyは、Mavenと言うよりもはるかに強力で、あまり意見のない依存関係管理ツールです。

Gradleは、プロジェクト間およびプロジェクトとJAR間の依存関係を検出します。Gradleは、iBiblio 1または独自のリポジトリのようなMavenリポジトリ（ダウンロードおよびアップロード）で動作しますが、他の種類のリポジトリインフラストラクチャもサポートします。

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

Gradleは、邪魔にならないように一生懸命努力します。Mavenが行うことはほとんどありません。コンベンションは良いですが、柔軟性も良いです。Gradleは、Mavenよりもはるかに多くの機能を提供しますが、最も重要なこととして、多くの場合、GradleはMavenから離れる痛みのない移行パスを提供します。

于 2009-10-07T23:44:24.443 に答える
64

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

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

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

  • 設定より規約（ala Maven）に従いますが、必要な範囲でのみ使用できます
  • Antのように柔軟なカスタムタスクを作成できます
  • AntとMavenの両方よりも優れたマルチモジュールプロジェクトサポートを提供します
  • 80％を簡単にし、20％を可能にするDSLを備えています（80％を簡単にし、10％を可能にし、10％を事実上不可能にする他のビルドツールとは異なります）。

Gradleは、私がまだ使用していない中で最も構成可能で柔軟なビルドツールです。DSLや構成などの概念を学ぶには、事前にいくらかの投資が必要ですが、ナンセンスで完全に構成可能なJVMビルドツールが必要な場合は、これに勝るものはありません。

于 2011-12-28T04:23:16.893 に答える
49

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タスクを、より優れたGroovyのような構文でgradleで使用できます。

ant.copy(file:'a.txt', toDir:"xyz")

また

ant.with{
  delete "x.txt"
  mkdir "abc"
  copy file:"a.txt", toDir: "abc"
}
于 2010-05-02T15:35:03.210 に答える
35

Gradleを使用し、MavenやAntよりも選択しました。Antは私たちに完全な柔軟性を与え、IvyはMavenよりも優れた依存関係管理を提供しますが、マルチプロジェクトビルドに対する優れたサポートはありません。マルチプロジェクトビルドをサポートするために、多くのコーディングを行うことになります。また、慣例によるビルドがあると便利で、ビルドスクリプトがより簡潔になります。Mavenを使用すると、慣例によりビルドが必要になりすぎ、ビルドプロセスのカスタマイズがハックになります。また、Mavenはアーティファクトを公開するすべてのプロジェクトをプロモートします。プロジェクトをサブプロジェクトに分割しているが、すべてのサブプロジェクトを一緒にビルドしてバージョン管理したい場合があります。Mavenが設計されているものではありません。

Gradleを使用すると、Antの柔軟性を利用して、Mavenの慣例に従ってビルドできます。たとえば、独自のタスクで従来のビルドライフサイクルを延長するのは簡単です。また、必要がない場合は、規則を使用する必要はありません。Groovyは、XMLよりもコーディングに優れています。Gradleでは、ローカルファイルシステム上のプロジェクト間の依存関係を定義できます。各プロジェクトのアーティファクトをリポジトリに公開する必要はありません。最後に、GradleはIvyを使用しているため、優れた依存関係管理を備えています。これまでのところ、私にとっての唯一の本当の欠点は、成熟したEclipse統合がないことですが、Mavenのオプションはそれほど優れていません。

于 2010-07-06T00:40:58.080 に答える
21

これは私の答えではありませんが、間違いなく私に共鳴します。これは、2012年10月のThoughtWorksのテクノロジーレーダーからのものです。

AntやMavenのようなXMLベースのビルドツールで疲労を引き起こしているのは、怒っている先のとがった中括弧が多すぎることと、プラグインアーキテクチャが粗いことの2つです。構文の問題は生成を通じて対処できますが、プラグインアーキテクチャでは、プロジェクトがより複雑になるにつれて、ビルドツールが適切に拡張する機能が大幅に制限されます。プラグインは抽象化のレベルが間違っていると感じ、代わりにGradleやRakeなどの言語ベースのツールを好むようになりました。プラグインはよりきめ細かい抽象化と長期的な柔軟性を提供するからです。

于 2012-11-02T19:52:13.817 に答える
16

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

しかし、初日から私の気分は良くなり始めました。私はどこかに行きました。最初のantモジュールを移行するのに2時間ほどかかりましたが、ビルドファイルは基本的に何もありませんでした。1つの画面に簡単に取り付けられます。大きな「すごい」は、xmlでスクリプトを作成することでしたが、それはどれほど愚かでしょうか。1つの依存関係を宣言すると1行かかるという事実は、私にとって非常に魅力的です->特定のプロジェクトのすべての依存関係を1ページで簡単に確認できます。それ以来、私は絶え間ない役割を果たしてきました。これまでに直面したすべての問題に対して、シンプルでエレガントな解決策があります。私はこれらが理由だと思います：

  • groovyはJava開発者にとって非常に直感的です
  • ドキュメントは素晴らしいものから素晴らしいものまで
  • 柔軟性は無限大です

今、私はビルドプロセスに追加する新機能を考えようと日々を過ごしています。それはどのくらい病気ですか？

于 2012-05-23T19:07:59.037 に答える
8

また、ネイティブビルドの管理もはるかに簡単です。AntとMavenは事実上Javaのみです。いくつかのネイティブプロジェクトを処理しようとするMaven用のプラグインがいくつか存在しますが、それらは効果的な仕事をしません。ネイティブプロジェクトをコンパイルするAntタスクを作成することはできますが、複雑すぎて扱いにくいものです。

JNIと他の多くのネイティブビットを使用してJavaを実行します。Gradleは、Antの混乱を大幅に簡素化しました。ネイティブプロジェクトに依存関係管理を導入し始めたとき、それは厄介でした。私たちはMavenにそれをやらせましたが、同等のGradleコードは、Mavenで必要とされるもののごく一部であり、人々はMavenの達人になることなく、それを読んで理解することができました。

于 2012-01-23T20:09:57.653 に答える
3

私はエド・スタウブに部分的に同意します。Gradleは、Mavenと比較して間違いなく強力であり、長期的にはより高い柔軟性を提供します。

MavenからGradleに移行するための評価を実行した後、gradleで発生した2つの問題（速度がMavenより遅い、プロキシが機能していなかった）について、Maven自体に固執することにしました。

于 2012-11-24T10:31:38.593 に答える