Gradle:build.gradle vs. settings.gradle vs. gradle.properties
1. 概要
この記事では、we’ll look at the different configuration files of a Gradle Java project。 Also, we’ll see the details of an actual build.
Gradleの概要については、this articleを確認できます。
2. build.gradle
gradle init –type java-applicationを実行して新しいJavaプロジェクトを作成していると仮定しましょう。 これにより、次のディレクトリとファイル構造を持つ新しいプロジェクトが残ります。
build.gradle
gradle
wrapper
gradle-wrapper.jar
gradle-wrapper.properties
gradlew
gradlew.bat
settings.gradle
src
main
java
App.java
test
java
AppTest.java
build.gradleファイルは、プロジェクトの心臓部または頭脳と見なすことができます。 この例の結果ファイルは次のようになります。
plugins {
id 'java'
id 'application'
}
mainClassName = 'App'
dependencies {
compile 'com.google.guava:guava:23.0'
testCompile 'junit:junit:4.12'
}
repositories {
jcenter()
}
これは、Groovyコード、より正確には、ビルドを記述するためのGroovyベースのDSL(ドメイン固有言語)で構成されています。 ここで依存関係を定義し、依存関係の解決に使用されるMavenリポジトリーなどを追加することもできます。
Gradleの基本的な構成要素は、プロジェクトとタスクです。 この場合、javaプラグインが適用されるため、Javaプロジェクトを構築するために必要なすべてのタスクが暗黙的に定義されます。 これらのタスクには、assemble、check、build、jar、javadoc、cleanなどがあります。
これらのタスクも、Javaプロジェクトの有用な依存関係グラフを記述するように設定されています。つまり、ビルドタスクを実行するだけで通常は十分であり、Gradle(およびJavaプラグイン)は必要なすべてのタスクが実行されることを確認します。 。
Dockerイメージの構築など、追加の特殊なタスクが必要な場合は、build.gradleファイルにも移動します。 タスクの最も簡単な定義は次のようになります。
task hello {
doLast {
println 'Hello example!'
}
}
次のように、Gradle CLIの引数として指定することにより、タスクを実行できます。
$ gradle -q hello
Hello example!
何の役にも立ちませんが、「こんにちは例」を印刷してください。もちろん。
マルチプロジェクトビルドの場合、プロジェクトごとに1つずつ、複数の異なるbuild.gradleファイルが存在する可能性があります。
build.gradleファイルはProjectインスタンスに対して実行され、サブプロジェクトごとに1つのプロジェクトインスタンスが作成されます。 上記のタスクは、build.gradleファイルで定義でき、Taskオブジェクトのコレクションの一部としてProjectインスタンス内にあります。 タスク自体は、順序付きリストとして複数のアクションで構成されています。
前の例では、「Helloexample!」を印刷するためのGroovyクロージャを追加しました。このリストの最後に、helloTaskオブジェクトでdoLast(Closure action)を呼び出します。 Taskの実行中、GradleはAction.execute(T)メソッドを呼び出して、各Actionsを順番に実行しています。
3. settings.gradle
Gradleはsettings.gradleファイルも生成します:
rootProject.name = 'gradle-example'
settings.gradleファイルもGroovyスクリプトです。
build.gradleファイルとは対照的に、Gradleビルドごとに実行されるsettings.gradleファイルは1つだけです。 これを使用して、マルチプロジェクトビルドのプロジェクトを定義できます。
また、ビルドのさまざまなライフサイクルフックの一部としてコードを登録することもできます。
フレームワークでは、マルチプロジェクトビルドにsettings.gradleが存在する必要がありますが、シングルプロジェクトビルドではオプションです。
このファイルは、ビルドのSettingsインスタンスを作成した後、ファイルを実行して構成することにより使用されます。 これは、settings.gradleファイルで次のようにサブプロジェクトを定義していることを意味します。
include 'foo', 'bar'
Gradleは、ビルドの作成時にSettingsインスタンスでvoid include(String… projectPaths)メソッドを呼び出しています。
4. gradle.properties
Gradleはデフォルトではgradle.propertiesファイルを作成しません。 プロジェクトのルートディレクトリ、GRADLE_USER_HOME内、または-Dgradle.user.homeコマンドラインフラグで指定された場所など、さまざまな場所に配置できます。
このファイルはキーと値のペアで構成されています。 これを使用してフレームワーク自体の動作を構成できます。これは、構成にコマンドラインフラグを使用する代わりに使用できます。
可能なキーの例は次のとおりです。
-
org.gradle.caching=(true,false)
-
org.gradle.daemon=(true,false)
-
org.gradle.parallel=(true,false)
-
org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)
また、このファイルを使用して、プロパティをProjectオブジェクトに直接追加できます。たとえば、名前空間を持つプロパティ:org.gradle.project.property_to_set
別の使用例では、次のようなJVMパラメーターを指定しています。
org.gradle.jvmargs=-Xmx2g -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
gradle.propertiesファイルを解析するには、JVMプロセスを起動する必要があることに注意してください。 つまり、これらのJVMパラメーターは、個別に起動されたJVMプロセスにのみ影響します。
5. 一言で言えばビルド
Gradleビルドをデーモンとして実行しないと仮定すると、Gradleビルドの一般的なライフサイクルを次のように要約できます。
-
新しいJVMプロセスとして起動します
-
gradle.propertiesファイルを解析し、それに応じてGradleを構成します
-
次に、ビルド用のSettingsインスタンスを作成します
-
次に、Settingsオブジェクトに対してsettings.gradleファイルを評価します
-
構成されたSettingsオブジェクトに基づいて、Projectsの階層を作成します
-
最後に、プロジェクトに対して各build.gradleファイルを実行します
6. 結論
さまざまなGradle構成ファイルがさまざまな開発目的をどのように満たすかを見てきました。 これらを使用して、プロジェクトのニーズに基づいて、GradleビルドとGradle自体を構成できます。