1. 概要

この記事では、GradleJavaプロジェクトのさまざまな構成ファイルを見ていきます。 また、実際のビルドの詳細が表示されます。

Gradleの一般的な紹介については、この記事を確認してください。

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プロジェクトを構築するために必要なすべてのタスクが暗黙的に定義されます。 これらのタスクには、アセンブルチェックビルド jar javadoc クリーン[ X116X]およびその他多数。

これらのタスクも、Javaプロジェクトの有用な依存関係グラフを記述するように設定されています。つまり、ビルドタスクを実行するだけで一般的に十分であり、Gradle(およびJavaプラグイン)がすべてを確認します。必要なタスクが実行されます。

Dockerイメージのビルドなど、追加の特殊なタスクが必要な場合は、build.gradleファイルにも移動します。 タスクの最も簡単な定義は次のようになります。

task hello {
    doLast {
        println 'Hello Baeldung!'
    }
}

次のように、GradleCLIへの引数としてタスクを指定することでタスクを実行できます。

$ gradle -q hello
Hello Baeldung!

何の役にも立ちませんが、「HelloBaeldung!」を印刷してください。 もちろん。

マルチプロジェクトビルドの場合、プロジェクトごとに1つずつ、複数の異なるbuild.gradleファイルが存在する可能性があります。

build.gradle ファイルは、 Project インスタンスに対して実行され、サブプロジェクトごとに1つのProjectインスタンスが作成されます。 上記のタスクは、 build.gradle ファイルで定義でき、Taskオブジェクトのコレクションの一部としてProjectインスタンス内にあります。 タスク自体は、順序付きリストとしての複数のアクションで構成されています。

前の例では、「HelloBaeldung!」を印刷するためのGroovyクロージャを追加しました。 このリストの最後に、 hello Taskオブジェクトで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インスタンスでvoidinclude(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.gradleファイルをSettingsオブジェクトに対して評価します
  • 構成された設定オブジェクトに基づいて、プロジェクトの階層を作成します
  • 最後に、プロジェクトに対して各build.gradleファイルを実行します

6. 結論

さまざまなGradle構成ファイルがさまざまな開発目的をどのように満たすかを見てきました。 これらを使用して、プロジェクトのニーズに基づいて、GradleビルドとGradle自体を構成できます。