web-dev-qa-db-ja.com

gradle.propertiesとsettings.gradleを使用する場合

Gradleビルドには3つのファイルがあります

  • ビルド構成スクリプトを定義するbuild.gradle
  • gradle.properties
  • settings.gradle

質問

  • settings.gradleとgradle.propertiesの違いは何ですか？
  • settings.gradle vs. gradle.propertiesに設定を配置する必要があるのはいつですか？
javagradlebuildbuild-system
59
ams

settings.gradle

settings.gradleファイルは、build.gradleファイルと同様に、Groovyスクリプトです。各ビルドで実行されるsettings.gradleスクリプトは1つだけです（マルチプロジェクトビルドの複数のbuild.gradleスクリプトと比較して）。 settings.gradleスクリプトは、build.gradleスクリプトの前、および Project インスタンスが作成される前でも実行されます。したがって、 Settings オブジェクトに対して評価されます。このSettingsオブジェクトを使用すると、サブプロジェクトをビルドに追加し、コマンドラインからパラメーターを変更し（ StartParameter ）、ライフサイクルハンドラーを登録するために Gradle オブジェクトにアクセスできます。結果として、設定がビルド関連であり、必ずしもプロジェクト関連である必要がない場合、またはロジックが必要な場合は、settings.gradleを使用してくださいbefore可能なサブプロジェクトが含まれます。

gradle.properties

gradle.propertiesファイルは、単純なJava Properties ファイルであり、Projectオブジェクトのスコープに自動的に含まれることによって特別な役割を獲得します（いわゆる「プロジェクトプロパティ」として）。これは、文字列値のみを許可する単純なキー値ストアです（したがって、リストまたは配列を自分で分割する必要があります）。次の場所にgradle.propertiesファイルを配置できます。

  • プロジェクトディレクトリに直接（プロジェクト関連の値用）
  • ユーザーのホーム.gradleディレクトリ（ユーザーまたは環境関連の値用）
64
Lukas Körfer

マルチモジュールプロジェクトには、1つのメインモジュールと多くのサブモジュールがあります。このレイアウトは次のとおりです。

(root)
  +- settings.gradle       
  +- build.gradle
  +- gradle.properties     # optional
  +-- buildSrc/            # optional
  |     +- build.gradle    # optional
  |     +-- src/           # optional
  |     +-- test/          # optional
  +-- gradle/              # optional
  |     +- utils.gradle    # optional
  +-- sub-a/
  |     +- build.gradle
  |     +- src/
  +-- sub-b/
        +- build.gradle
        +- src/

サブモジュールはサブフォルダーのより深い場所に配置することもできますが、settings.gradleのコードを変更しなければ、その名前にはそのようなフォルダーの名前が含まれます。

settings.gradle

Settings.gradleの主な役割は、含まれるすべてのサブモジュールを定義し、モジュールのツリーのディレクトリルートをマークすることです。したがって、マルチモジュールプロジェクトで使用できるsettings.gradleファイルは1つだけです。

rootProject.name = 'project-x'

include 'sub-a', 'sub-b'

設定ファイルもgroovyで書かれており、サブモジュールのルックアップをカスタマイズできます。

build.gradle

モジュールごとにこのようなファイルが1つあり、このモジュールのビルドロジックが含まれています。

メインモジュールのbuild.gradleファイルでは、allprojects {}またはsubprojects {}を使用して、他のすべてのモジュールの設定を定義できます。

サブモジュールのbuild.gradleファイルでは、compile project(':sub-a')を使用して、1つのサブモジュールを他のサブモジュールに依存させることができます。

gradle.properties

これはオプションです。その主な目的は、gradle自体の実行に使用するスタートアップオプションを提供することです。

org.gradle.jvmargs=-Xmx=... -Dfile.encoding=UTF-8 ...
org.gradle.configureondemand=true

これらの値は、ファイルUSER_HOME/.gradle/gradle.propertiesでオーバーライドでき、gradleコマンドライン引数でオーバーライドできます。また、systemProp.をプレフィックスとして使用して、このファイルでビルドの環境変数を設定することもできます。

このファイルのプロパティはbuild.gradleで使用できるため、一部のプロジェクトは依存関係のバージョンまたはリリース情報もgradle.propertiesに配置しますが、これはおそらくこのファイルの悪用です。

gradle/utils.gradle

（任意の名前のフォルダーまたはファイルが可能です。）追加のカスタムgradleファイルを定義して定義を再利用し、次の方法で他のgradleファイルに含めることができます

apply from: "$rootDir/gradle/utils.gradle"

buildSrc/...

このフォルダーは特別で、それ自体が個別のgradleプロジェクトのようなものです。それは他の何かをする前に構築され、他のgradleファイルで使用する機能を提供できます。 技術的な理由により、このフォルダーへの参照のIDEサポートは、複数のbuild.gradleファイルから別の場所に共通コードを抽出する他の方法よりもはるかに機能します。複雑なカスタムを定義できますプラグインを記述してデプロイする代わりに、Java、groovy、またはkotlinでロジックを構築します。これは、ユニットテストを実行できるため、カスタムビルドコードのユニットテストにも役立ちます。

42
tkruse