34

buildSrcGradleでは、通常のJavaプロジェクトレイアウト（src / main / java）ではなく、ファイルをトップレベルとして使用する目的は何ですか？

のレイアウトがある場合

src
   main
      java

また

buildSrc
    src
       main
          java

違い（またはこれを行う理由）は何でしょうか？マルチモジュールプロジェクトでより便利ですか？マルチモジュールプロジェクトでも、こんなことはできませんでした

proj1
  src


proj2
  src

そして、プロジェクト全体で共通の設定を定義するトップレベルのbuild.gradle（とと同じレベル）がありますproj1か？proj2

4

2 に答える 2

62

buildSrcは、メインビルドのビルドスクリプトで使用することを目的としたタスク、プラグイン、またはその他のクラスをビルドすることを目的とした別個のビルドですが、ビルド間で共有する必要はありません。（*）このようなクラスは、メインビルドのビルドスクリプトをコンパイル/評価する前に存在する必要があるため、メインビルドの一部としてビルドできます。また、Gradleは、作業を行う前にすべてのビルドスクリプトをコンパイル/評価します（構成フェーズと実行フェーズ）。 。

すべてのビルドコードをビルドスクリプトに入れるのと比較して、buildSrcテストしたり、IDEにインポートしたりできるクラスとして、通常のコードのようにビルドコードを開発する方法があります。これは、ビルドスクリプトをシンプルに保ち、より複雑なビルド。

buildSrcビルドが大きいほど独自のカスタムタスクとプラグインを実装する可能性が高いという理由だけで、マルチプロジェクトビルドでよく見られます。

時間の経過とともに、単一のGradle呼び出しで複数の依存ビルドbuildSrcを実行するより一般的な機能に成長します。

（*）ビルド間でクラスを共有することは可能ですが、より複雑です。特に、クラスをリポジトリに公開する必要があり、ビルド間で本番ライブラリを共有する場合と同様に、消費するビルドはそこから明示的にクラスをインポートする必要があります。

于 2012-12-14T08:54:02.980 に答える
8

Gradleでは、一般的なJavaプロジェクトレイアウト（src / main / java）ではなく、buildSrcファイルをトップレベルとして使用する目的は何ですか？

あなたは間違いなくこれを行うことができます。これはgradleの複合ビルドとして知られていますが、そのフォルダーからのビルドを含めるようにGradleに指示する必要があります。トップレベルフォルダーのユニークなプロパティbuildSrcは、gradleがそれをインクルードビルドとして自動的に処理することです。

buildSrc複合ビルドとして扱われていても、を実行すると、含まれているビルドのリストに表示されないことに注意してくださいgradle.getIncludedBuilds()。その理由は、リストが手動でに含めたビルド用に予約されているためだと思いますsettings.gradle。

複合ビルドとしても含めるにはsrc/main/java、フラグを使用してgradleスクリプトを実行し--include-build、その後にへのパスを続ける必要がありますsrc/main/java。これは、含まれているビルドとしては珍しい場所ですが、gradleは文句を言いません。

そして、プロジェクト全体で共通の設定を定義するトップレベルのbuild.gradle（proj1およびproj2と同じレベル）がありますか？

、およびサブプロジェクトとbuild.gradle同じレベルのトップレベルを持つことができます。これは通常、ほとんどのマルチプロジェクトプロジェクトの構造です。proj1proj2

すでに強調した別の回答として、プロジェクトの目的は、ビルド内のさまざまなプロジェクト間でローカルに共有されることをbuildSrc目的としたカスタムプラグインまたはタスクを作成することです。これは、トップレベルでこれらのカスタムタスクとプラグインを作成できないことを意味するものではありません。この方法でそれを行うことができますが、問題は、どのサブプロジェクトでもそれを使用できないことです。build.gradle

java / groovyに何かをインポートできるようにするには、それが適切なjava / groovyファイル（またはjava 9以降のモジュール）に存在する必要があることに注意してください。あなたbuild.gradleは単なるスクリプトであるため、プラグインやタスクをそこからインポートすることは恣意的ではありません。

私がすでに指摘したように、これはGradleのドキュメントbuildSrcからのものですが、ディレクトリを持つ理由の1つは次のとおりです。

ディレクトリが検出されると、Gradleはこのコードを自動的にコンパイルしてテストし、ビルドスクリプトのクラスパスに配置します。

ご覧のとおりbuildSrc、プロジェクトのすべてのビルドスクリプトに機能を追加できるという点で、ビルドプロセスの拡張として機能します。

さらにいくつかのポイント：

  • dependenciesで宣言されたものはすべてbuildSrc/build.gradle、プロジェクトの残りのビルドスクリプトに表示されます。
  • あなたのbuildscriptブロックは、他buildSrc/build.gradleには何も見えbuildSrc/build.gradleません。
  • で定義されたプラグインクラスは、プロジェクトのビルドスクリプトでbuildSrc 使用でき、で宣言する必要はありませんMETA-INF/gradle-plugins。
  • メインbuild.gradleプロジェクトまたはサブプロジェクトで定義されている依存関係は、に表示されませんbuildSrc。このフォルダーがインクルードビルド（つまり外部）として扱われることを覚えている場合は、それを含むプロジェクトのクラスパスを表示できない理由が理解できるはずです。
于 2019-07-13T03:00:28.680 に答える