なぜグラドルなのか？

それでもGradleが何であるかわからない場合は、前の2つのレビューでそれについて読むことができます：

1. Gradle：より良い構築方法
2. Gradle：タスクはコードです

少し前、MavenからGradleに、 Hibernate Coreアセンブリが転送されました。 情報コミュニティが曖昧に反応したもの。 Hibernateアセンブリの移行に関する記事の翻訳に注目してください。 この記事では、この決定を行う理由を明らかにし、Gradleの利点とMaven2の問題について説明します。 さらなるナレーションは、Steve Ebersoleに代わって行われます。

なぜグラドルなのか？

多くの人が、HibernateアセンブリをMavenからGradleに転送したい理由を書き留めてほしいと頼みました。ここにそれらをリストします。 Gradleに出会うのがこれが初めての場合は、 概要をご覧ください 。 まず第一に、この記事の目的は「クラッシュを打つ-Maven」ではなく、GradleとMavenを直接比較することではないことを強調したいと思います。 これは、Mavenを使用してHiberbnateを構築した2.5年以上の間に遭遇した問題やフラストレーションについて世界に伝えるための単なる方法です。 多くの場合、その理由は、Mavenで使用される規則が、Hibernateアセンブリを想像する方法と一致しないためです。 Paulによってコンパイルされたリストの一部の項目は、Hibernateにのみ関連しています（このリストも一見の価値があります）。 これは、私が他の新しいビルドツール（ビルダー、SBTなど）よりもGradleを好んだ理由を説明する方法でもあります。 ところで、GradleとMavenを比較するwikiもありますが、多くの部分でかなり時代遅れです。 特にGradleで。



以下は、Mavenで遭遇した問題（「重要性」よりも時系列順）です。

1. Mavenはマルチモジュールアセンブリをサポートしていません。 サポートすると主張されていますが、これは完全に正確ではありません。 正確には、 独立したプロジェクトのグループの側面をサポートします 。 違いは何ですか？ たとえば、Hibernateを使用します。 組み立てるモジュールのセットがあります。 モジュールは、使用する機能に応じて依存関係を分離する目的でのみ存在します。 キャッシュにehcacheを使用していませんか？ 問題ありません。hibernate-ehcacheモジュールを使用しないでください。ehcacheは依存関係にありません。 これらのモジュールを個別に提供することはありません。 次に、なぜプロジェクトバージョンを何度も（すべてのモジュールで）設定する必要があるのですか？ mavenが単純なものを複雑にする方法の例を次に示します。 そして、結果は、例えば、私がリリースをしたいときに感じられます。 バージョンが多くの異なる場所で一致することを手動で確認する必要があります（リリースプラグインについても開始しないでください）
2. さて、リリースプラグインについて始めたので。 一般に役に立たない。 小さなプロジェクトで多かれ少なかれうまく動作させることができましたが、Hibernateを使用するとほとんど常に「クラッシュ」しました。 さらに悪いことに、あなたはそれがうまくいかないことを見つけるために30-40-60分待ってから、彼が気に入らなかったものを修正して（あなたがなんとか見つけたなら）、それを再び始めなければなりません。 最終的に、私たちはあきらめました 。 （ちなみに、友人はJason van Zylがリリースプラグインを地獄の第7サークルにキャストし、「新しいもの」に置き換えられることに気付いたところです）
3. Hibernate-coreは主要な成果物です。 Hibernate-Annotationsはそれに依存します。 Mavenはこれについて知っています。 それでは、なぜhibernate-annotationsディレクトリに移動して 'maven compile'を実行してhibernate-coreも自動的にビルドできないのはなぜですか？ （ヒント：ポイント1を参照）いずれの場合でも： `cd hibernate-core; mvn install; cd ../hibernate-annotations; mvn compile`-はゲートに登りません。 ビルドインストーラーは、私が非常に多くの障害を克服し、これらの依存関係の性質を説明した後、自分でこれを理解する必要があります。
4. プロジェクトごとに1つのアーティファクト。 これは良いルールだと思います。 しかし、良いルールが絶対的な真実であることはめったにありません。 また、たとえば、Mavenのこの制限により、hibernate-coreの外部でhibernate-coreのテストを行う必要がありました。 hibernate-coreに依存し、テストの一般的な実行時間を定義し、他のほとんどのモジュールで使用されるhibernate-testingが必要だったため（ユーザーが利用できるようにしたかったため）。 開発者（自分を含む）がテストを実行するのを忘れているのは、他の完全に独立したモジュールに横たわっているためです。 はい、これは主に細部への注意の問題ですが、アセンブリツールはそれらの問題を作成するのではなく解決するのに役立つべきではありませんか？ さて、プロジェクトごとに1つのソースディレクトリとコンパイルされたクラスの1つのディレクトリ。 http：// in.relation.to / Bloggers / SimultaneouslySupportingJDBC3AndJDBC4WithMavenを参照してください
5. 個人的には、「継承されたPOMデータ」と「モジュール集約」を1つのファイルに結合するという概念が嫌いです。 これはひどい考えです。 多くのMaven開発者は私に同意し、Hibernateが./parent/pom.xmlに「継承されたpomデータ」を、。/ pom.xmlに「モジュール集約」を投稿するスキームの開発を支援しました。 素晴らしい、Mavenはそれをサポートしています...まあ、ほとんど問題ありません：ほとんどサポートしています。 問題は、多くのプラグインがこれをサポートしておらず、小さなキャッチーな問題が始まることです。 では、なぜそれを運ぶのでしょうか？ 私が言ったように、私は組合が正しいとは思わない。 しかし、なぜ「正しく」踏み越えて、違うやり方をしないのか。 Mavenの動作は異なりますか？ 問題は、初期チェックアウト後の設定にあります。 親が存在するまでモジュールを構築できません。 ただし、親がアグリゲーターの場合、モジュールをビルドする唯一の方法はプロジェクト全体をインストールすることです（またはmavenコマンドのキーを知って再帰をオフにします）
6. 当初、2.5年前、私はDocBookアセンブリに直面しなければなりませんでした。 クリスチャンは、HibernateでAntを使用してDocBookを構築することで、多くのオープンソースJavaプロジェクトの基準を設定しました。 依存関係管理の概念を使用して必要に応じて必要なコンポーネントをダウンロードし、これを改善する方法について考えました。 問題は、Mavenで同様のことを行うには、プラグインを作成する必要があることです。 「スクリプトを投げるだけで、それが有用であることが判明したら、他の人のためにそれをパックします」（GMavenなどの助けを借りればある程度可能になったが、そうではなかった） そのため、jDocBookプラグインなどを作成する必要がありました。 そして、それらすべてに問題がありました。 Gradleは「雄牛の目をたたく」ので、GradleとMavenを直接比較するのはこれだけです。 Gradleでプラグインを作成する（私はすでに2つの非常に大きなプラグインを作成しました）ことはとても素晴らしいことです。 ある意味では、これを正しく行う方法に関する指示がないため、これは簡単ではありませんが、提供されるAPIと機能は単純です（Mavenが「正しいプラグイン」に関するドキュメントを持っていたわけではありません）。
7. 多くのユーザーは、JBoss Mavenリポジトリと対話するようにビルドスクリプトを設定することを望んでいます。 論理的です：アセンブリはそのまま使用できます。 ただし、Mavenでは、アセンブリに使用されるpomファイルもリポジトリへのインストールに使用されるため、これを行うことはできません。 また、ほとんどのリポジトリ（JBossおよびMaven Centralを含む）は、pomファイルにリポジトリ設定が含まれていないことを確認します。 そのため、スクリプトを設定する代わりに、wikiとdocbookをサポートし、ユーザーをドキュメントに送る必要があります。
8. 統合を使用して、少なくともIntelliJでは、IDEを介して複数のデータベースでHibernateテストを実行することはほとんど不可能です。 問題はプロファイルにあり、統合がプロファイルとどのように相互作用するか（リソースのフィルタリングに関して）

だから、Hibernateを構築するためのより良い方法を探し始める時です。 はい、Maven3は地平線上に迫ってきました。 はい、彼はいくつかの「スクリプトサポート」を追加しますが、それは小さなことのようです。 私の知る限り、同じ方法で別の方法でセットアップできます。 そこで、他の「DSL、慣習ごとに構築する」ツールの中で、Gradleを学び始めました。 （ちなみに、この「小さなもの」はポリグロットメイベンと呼ばれ、友人によると、ジェイソン・ファン・ジルは削除されて「他の何か」に置き換えられると述べた）。

1. 最初の主な利点は、「慣例による構築」の観点から説明するのが難しすぎるブロックの部分のスクリプトを作成できることでした。 私はこの混合物が好きでした：両方の世界からの最高はあなたの処分です。
2. アセンブリ中に他のモジュールの情報にアクセスするのが困難な場合[Maven2を使用-約 trans。]、私は、多くの場合、クロージャーを使用してアセンブリモジュールの列挙を記述する機能は、単に「神の贈り物」であることに気付きました。 メインgradleスクリプトのすべてのサブプロジェクトの標準設定を構成する方法と同様に、これはMavenの継承の概念をはるかに超える傑作です。
3. ビルドシステムの制限に従う必要なしに、必要に応じてビルド設定とディレクトリの一般的な柔軟性-それは素晴らしい
4. Gradleのビルドプロセスの全体的な概念は、はるかに簡潔です。 Gradleでは、モジュール間の依存関係を定義できるだけでなく、タスク、モジュール、ディレクトリなどの依存関係を非常に柔軟に記述することもできます。 たとえば、Gradleでは、1つのモジュールが別のアセンブリの結果（jar）ではなく、コンパイルされたクラスに依存していると既に言うことができます。 考えてみてください。 非常に柔軟です。 そして便利！
5. 各プロジェクトまたはモジュールには、複数の「ソースセット」を含めることができます。 「ソースセット」は、ソースコード、ターゲットディレクトリのセット、リソースディレクトリなどを含むディレクトリセットを設定します。これにより、たとえば、JDBC3 / JDBC4の並列サポートとテストを希望どおりに行うことができます（ in.relationを参照） .to /ブロガー/ SimultaneouslySupportingJDBC3AndJDBC4WithMaven ）
6. 何に起因するのかわかりませんが、「アセンブリシステムにはどのようなオプションがありますか？」ではなく、「どうやってこれを行うのですか？」
7. 増分アセンブリは素晴らしいです。 どう？ 彼女は、何かが変わったとき、変わっていないとき、そしてアセンブリの部品が実際に必要なときを理解しています。 これはプラグインに組み込まれています。 タスクは入力と出力を決定し、Gradleはこの情報を使用してタスクを実行する必要があるかどうかを決定します。 入力が変更され、タスクが出力を更新したかどうか、したがって、それに依存するタスクを実行する必要があります。 その結果、後続のビルドは非常に高速になります。
8. Mavenリポジトリにアーティファクトを公開し、正確なPOMを生成するGradleの機能は、ユニークであるだけでなく、移行を決定するための重要な議論でもありました。 Mavenを使用してHibernateを構築することに苦情を言うかもしれませんが、アーティファクトを統一された方法で作成および使用する機能が非常に必要です。 一般に、Gradleは、持っている情報からPOMを生成できます。 そうでない場合は、クロージャーに追加のパラメーターを記述するだけでPOMを構成できます。 これは柔軟性に関するものです。
9. IDEプロジェクトの生成。 これは別の重要な議論でした。 ほとんどのHibernate開発者はEclipseまたはIntelliJを使用します。 個人的に、私はIDEでほとんどの時間を費やしています。コードを記述し、テストを実行し、ドキュメントを作成します。 IDEの作業を複雑にすることはしませんでした。 かなり長い間、GradleはEclipseでプロジェクトを作成できます。 最近、IntelliJでプロジェクトを生成できるようになりました。 彼女のために、彼らは言う、mavenに似たgradle統合が開発されている