1. 導入

Spring Boot Gradle プラグインは、Gradle (英語) で Spring Boot サポートを提供します。これにより、実行可能な jar または war アーカイブをパッケージ化し、Spring Boot アプリケーションを実行し、spring-boot-dependencies が提供する依存関係管理を使用できます。Spring Boot の Gradle プラグインには、Gradle 6.8、6.9,, 7.x が必要であり、Gradle の構成キャッシュ (英語) で使用できます。

このユーザーガイドに加えて、API ドキュメントも利用できます。

2. 入門

プラグインを開始するには、プロジェクトに適用する必要があります。

プラグインは Gradle のプラグインポータルに公開 (英語) され、plugins ブロックを使用して適用できます。

Groovy
plugins {
	id 'org.springframework.boot' version '2.6.3'
}
Kotlin
plugins {
	id("org.springframework.boot") version "2.6.3"
}

プラグインを単独で適用すると、プロジェクトにいくつかの変更が加えられます。代わりに、プラグインは他の特定のプラグインが適用されたときにそれを検出し、それに応じて反応します。例: java プラグインが適用されると、実行可能な jar を構築するためのタスクが自動的に構成されます。典型的な Spring Boot プロジェクトでは、groovy (英語) 、java (英語) 、org.jetbrains.kotlin.jvm (英語) プラグインを最低限適用し、依存関係管理のために io.spring.dependency-management [GitHub] (英語) プラグインまたは Gradle のネイティブ bom サポートも使用します。例：

Groovy
apply plugin: 'java'
apply plugin: 'io.spring.dependency-management'
Kotlin
plugins {
	java
	id("org.springframework.boot") version "2.6.3"
}

apply(plugin = "io.spring.dependency-management")

他のプラグインが適用された場合の Spring Boot プラグインの動作の詳細については、他のプラグインへの反応に関するセクションを参照してください。

3. 依存関係の管理

Spring Boot アプリケーションの依存関係を管理するには、io.spring.dependency-management [GitHub] (英語) プラグインを適用するか、Gradle のネイティブ bom サポートを使用します。前者の主な利点は、管理対象バージョンのプロパティベースのカスタマイズを提供することですが、後者を使用すると、ビルドが高速になる可能性があります。

3.1. 依存関係管理プラグインによる依存関係の管理

io.spring.dependency-management [GitHub] (英語) プラグインを適用すると、Spring Boot のプラグインは、使用しているバージョンの Spring Boot から spring-boot-dependencies bom を自動的にインポートします。これにより、Maven ユーザーが享受するのと同様の依存関係管理エクスペリエンスが提供されます。例: bom で管理されている依存関係を宣言するときに、バージョン番号を省略できます。この機能を利用するには、通常の方法で依存関係を宣言しますが、バージョン番号は省略します。

Groovy
dependencies {
	implementation('org.springframework.boot:spring-boot-starter-web')
	implementation('org.springframework.boot:spring-boot-starter-data-jpa')
}
Kotlin
dependencies {
	implementation("org.springframework.boot:spring-boot-starter-web")
	implementation("org.springframework.boot:spring-boot-starter-data-jpa")
}

3.1.1. 管理バージョンのカスタマイズ

依存関係管理プラグインの適用時に自動的にインポートされる spring-boot-dependencies bom は、プロパティを使用して、管理する依存関係のバージョンを制御します。これらのプロパティの完全なリストについては、Spring Boot リファレンスの Dependency versions Appendix を参照してください。

管理対象バージョンをカスタマイズするには、対応するプロパティを設定します。例: slf4j.version プロパティによって制御される SLF4J のバージョンをカスタマイズするには:

Groovy
ext['slf4j.version'] = '1.7.20'
Kotlin
extra["slf4j.version"] = "1.7.20"
各 Spring Boot リリースは、サードパーティの特定の依存関係セットに対して設計およびテストされています。バージョンを上書きすると互換性の問題が発生する可能性があるため、注意して行う必要があります。

3.1.2. Spring Boot の依存関係管理のみを使用

Spring Boot の依存関係管理は、Spring Boot のプラグインをそのプロジェクトに適用せずにプロジェクトで使用できます。SpringBootPlugin クラスは、グループ ID、アーティファクト ID、バージョンを知らなくても BOM をインポートするために使用できる BOM_COORDINATES 定数を提供します。

まず、Spring Boot プラグインに依存するようにプロジェクトを構成しますが、適用しません。

Groovy
plugins {
	id 'org.springframework.boot' version '2.6.3' apply false
}
Kotlin
plugins {
	id("org.springframework.boot") version "2.6.3" apply false
}

Spring Boot プラグインの依存関係管理プラグインへの依存関係は、依存関係を宣言することなく依存関係管理プラグインを使用できることを意味します。これは、Spring Boot が使用するのと同じバージョンの依存関係管理プラグインを自動的に使用することも意味します。

依存関係管理プラグインを適用し、Spring Boot の bom をインポートするように構成します。

Groovy
apply plugin: 'io.spring.dependency-management'

dependencyManagement {
	imports {
		mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
	}
}
Kotlin
apply(plugin = "io.spring.dependency-management")

the<DependencyManagementExtension>().apply {
	imports {
		mavenBom(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
	}
}

上記の Kotlin コードは少し厄介です。これは、依存関係管理プラグインを必須の方法で適用しているためです。

ルートの親プロジェクトからプラグインを適用するか、Spring Boot プラグインで行っているように plugins ブロックを使用することで、コードをより扱いにくくすることができます。このメソッドの欠点は、依存関係管理プラグインのバージョンを指定する必要があることです:

plugins {
	java
	id("org.springframework.boot") version "2.6.3" apply false
	id("io.spring.dependency-management") version "1.0.11.RELEASE"
}

dependencyManagement {
	imports {
		mavenBom(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
	}
}

3.1.3. さらに学ぶ

依存関係管理プラグインの機能の詳細については、そのドキュメント (英語) を参照してください。

3.2. Gradle の Bom サポートによる依存関係の管理

Gradle を使用すると、BOM を使用して、プロジェクトを platform または enforcedPlatform 依存関係として宣言することにより、プロジェクトのバージョンを管理できます。platform 依存関係は、BOM 内のバージョンを推奨として扱い、依存関係グラフ内の他のバージョンと制約により、BOM で宣言されたもの以外のバージョンの依存関係が使用される場合があります。enforcedPlatform 依存関係は、BOM のバージョンを要件として扱い、依存関係グラフで見つかった他のバージョンをオーバーライドします。

次の例に示すように、SpringBootPlugin クラスは BOM_COORDINATES 定数を提供し、これを使用して、グループ ID、アーティファクト ID、バージョンを知らなくても、Spring Boot の bom への依存関係を宣言できます。

Groovy
dependencies {
	implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
}
Kotlin
dependencies {
	implementation(platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES))
}

プラットフォームまたは強制されたプラットフォームは、それが宣言された構成のバージョン、または宣言された構成から拡張された構成のバージョンのみを制約します。その結果、複数の構成で同じ依存関係を宣言する必要がある場合があります。

3.2.1. 管理バージョンのカスタマイズ

Gradle の bom サポートを使用する場合、spring-boot-dependencies のプロパティを使用して、それが管理する依存関係のバージョンを制御することはできません。代わりに、Gradle が提供するメカニズムの 1 つを使用する必要があります。そのようなメカニズムの 1 つが解決戦略です。SLF4J のモジュールはすべて org.slf4j グループにあるため、次の例に示すように、特定のバージョンを使用するようにそのグループのすべての依存関係を構成することにより、バージョンを制御できます。

Groovy
configurations.all {
	resolutionStrategy.eachDependency { DependencyResolveDetails details ->
		if (details.requested.group == 'org.slf4j') {
			details.useVersion '1.7.20'
		}
	}
}
Kotlin
configurations.all {
    resolutionStrategy.eachDependency {
        if (requested.group == "org.slf4j") {
            useVersion("1.7.20")
        }
    }
}
各 Spring Boot リリースは、サードパーティの特定の依存関係セットに対して設計およびテストされています。バージョンを上書きすると互換性の問題が発生する可能性があるため、注意して行う必要があります。

4. 実行可能アーカイブのパッケージ化

プラグインは、アプリケーションのすべての依存関係を含む実行可能アーカイブ（jar ファイルおよび war ファイル）を作成し、java -jar で実行できます。

4.1. 実行可能な jar のパッケージ化

bootJar タスクを使用して、実行可能 jar を構築できます。タスクは、java プラグインが適用されるときに自動的に作成され、BootJar (Javadoc) のインスタンスです。assemble タスクは bootJar タスクに依存するように自動的に構成されるため、assemble （または build）を実行すると bootJar タスクも実行されます。

4.2. 実行可能な war のパッケージ化

bootWar タスクを使用して、実行可能な war を構築できます。タスクは、war プラグインが適用されるときに自動的に作成され、BootWar (Javadoc) のインスタンスです。assemble タスクは bootWar タスクに依存するように自動的に構成されるため、assemble （または build）を実行すると bootWar タスクも実行されます。

4.2.1. 実行可能およびデプロイ可能な war のパッケージ化

war ファイルは、java -jar を使用して実行し、外部コンテナーにデプロイできるようにパッケージ化できます。これを行うには、providedRuntime 構成に埋め込みサーブレットコンテナーの依存関係を追加する必要があります。例:

Groovy
dependencies {
	implementation('org.springframework.boot:spring-boot-starter-web')
	providedRuntime('org.springframework.boot:spring-boot-starter-tomcat')
}
Kotlin
dependencies {
	implementation("org.springframework.boot:spring-boot-starter-web")
	providedRuntime("org.springframework.boot:spring-boot-starter-tomcat")
}

これにより、外部コンテナーのクラスと競合しない war ファイルの WEB-INF/lib-provided ディレクトリに確実にパッケージ化されます。

providedRuntime は、Gradle の compileOnly 構成よりも優先されます。他の制限の中でも、compileOnly の依存関係はテストクラスパスにないため、Web ベースの統合テストは失敗します。

4.3. 実行可能アーカイブとプレーンアーカイブのパッケージ化

デフォルトでは、bootJar または bootWar タスクが構成されている場合、jar または war タスクは、アーカイブ分類子の規則として plain を使用するように構成されています。これにより、bootJar と jar、bootWar と war の出力場所が異なり、実行可能アーカイブとプレーンアーカイブの両方を同時に構築できます。

プレーンアーカイブではなく実行可能アーカイブで分類子を使用する場合は、jar および bootJar タスクの次の例に示すように分類子を構成します。

Groovy
bootJar {
	classifier = 'boot'
}

jar {
	classifier = ''
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	classifier = "boot"
}

tasks.getByName<Jar>("jar") {
	classifier = ""
}

または、プレーンアーカイブをまったく作成しない場合は、次の jar タスクの例に示すように、そのタスクを無効にします。

Groovy
jar {
	enabled = false
}
Kotlin
tasks.getByName<Jar>("jar") {
	enabled = false
}

4.4. 実行可能アーカイブパッケージの構成

BootJar (Javadoc) および BootWar (Javadoc) タスクは、それぞれ Gradle の Jar および War タスクのサブクラスです。その結果、jar または war をパッケージ化するときに使用できるすべての標準構成オプションは、実行可能な jar または war をパッケージ化するときにも使用できます。実行可能な jar および war に固有の構成オプションも多数提供されています。

4.4.1. メインクラスの構成

デフォルトでは、実行可能アーカイブのメインクラスは、タスクのクラスパス上のディレクトリで public static void main(String[]) メソッドを持つクラスを探すことにより自動的に構成されます。

メインクラスは、タスクの mainClass プロパティを使用して明示的に構成することもできます。

Groovy
bootJar {
	mainClass = 'com.example.ExampleApplication'
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	mainClass.set("com.example.ExampleApplication")
}

または、Spring Boot DSL の mainClass プロパティを使用して、プロジェクト全体でメインクラス名を設定できます。

Groovy
springBoot {
	mainClass = 'com.example.ExampleApplication'
}
Kotlin
springBoot {
	mainClass.set("com.example.ExampleApplication")
}

application プラグイン (英語) が適用されている場合は、その mainClass プロパティを構成する必要があり、同じ目的で使用できます。

Groovy
application {
	mainClass = 'com.example.ExampleApplication'
}
Kotlin
application {
	mainClass.set("com.example.ExampleApplication")
}

最後に、タスクのマニフェストで Start-Class 属性を構成できます。

Groovy
bootJar {
	manifest {
		attributes 'Start-Class': 'com.example.ExampleApplication'
	}
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	manifest {
		attributes("Start-Class" to "com.example.ExampleApplication")
	}
}
メインクラスが Kotlin で記述されている場合は、生成された Java クラスの名前を使用する必要があります。デフォルトでは、これは Kt サフィックスが追加された Kotlin クラスの名前です。例: ExampleApplication は ExampleApplicationKt になります。@JvmName を使用して別の名前が定義されている場合は、その名前を使用する必要があります。

4.4.2. 開発専用の依存関係を含める

デフォルトでは、developmentOnly 構成で宣言されたすべての依存関係は、実行可能な jar または war から除外されます。

developmentOnly 構成で宣言された依存関係をアーカイブに含める場合は、次の bootWar タスクの例に示すように、そのタスクのクラスパスを構成に含めるように構成します。

Groovy
bootWar {
	classpath configurations.developmentOnly
}
Kotlin
tasks.getByName<BootWar>("bootWar") {
	classpath(configurations["developmentOnly"])
}

4.4.3. 解凍が必要なライブラリの構成

ほとんどのライブラリは、実行可能アーカイブにネストされている場合に直接使用できますが、特定のライブラリには問題がある場合があります。例: JRuby には、jruby-complete.jar が常にファイルシステムで直接利用可能であることを前提とする独自のネストされた jar サポートが含まれています。

問題のあるライブラリを処理するために、実行可能アーカイブの実行時に、特定のネストされた jar を一時ディレクトリに解凍するように実行可能アーカイブを構成できます。ライブラリは、ソース jar ファイルの絶対パスと一致する Ant スタイルのパターンを使用して解凍する必要があると識別できます。

Groovy
bootJar {
	requiresUnpack '**/jruby-complete-*.jar'
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	requiresUnpack("**/jruby-complete-*.jar")
}

さらに制御するために、クロージャを使用することもできます。クロージャには FileTreeElement が渡され、開梱が必要かどうかを示す boolean を返す必要があります。

4.4.4. アーカイブを完全に実行可能にする

Spring Boot は、完全に実行可能なアーカイブのサポートを提供します。アーカイブは、アプリケーションの起動方法を知っているシェルスクリプトを先頭に追加することにより、完全に実行可能になります。Unix ライクなプラットフォームでは、この起動スクリプトにより、アーカイブを他の実行可能ファイルのように直接実行したり、サービスとしてインストールしたりできます。

現在、一部のツールはこの形式を受け入れないため、この手法を常に使用できるとは限りません。例: jar -xf は、完全に実行可能にされた jar または war の抽出にサイレントに失敗する場合があります。このオプションは、java -jar で実行したり、サーブレットコンテナーにデプロイしたりするのではなく、直接実行する場合にのみ有効にすることをお勧めします。

この機能を使用するには、起動スクリプトの組み込みを有効にする必要があります。

Groovy
bootJar {
	launchScript()
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	launchScript()
}

これにより、Spring Boot のデフォルトの起動スクリプトがアーカイブに追加されます。デフォルトの起動スクリプトには、適切なデフォルト値を持ついくつかのプロパティが含まれています。値は、properties プロパティを使用してカスタマイズできます。

Groovy
bootJar {
	launchScript {
		properties 'logFilename': 'example-app.log'
	}
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	launchScript {
		properties(mapOf("logFilename" to "example-app.log"))
	}
}

デフォルトの起動スクリプトがニーズを満たさない場合、script プロパティを使用してカスタム起動スクリプトを提供できます。

Groovy
bootJar {
	launchScript {
		script = file('src/custom.script')
	}
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	launchScript {
		script = file("src/custom.script")
	}
}

4.4.5. PropertiesLauncher の使用

PropertiesLauncher を使用して実行可能な jar または war を起動するには、タスクのマニフェストを構成して Main-Class 属性を設定します。

Groovy
bootWar {
	manifest {
		attributes 'Main-Class': 'org.springframework.boot.loader.PropertiesLauncher'
	}
}
Kotlin
tasks.getByName<BootWar>("bootWar") {
	manifest {
		attributes("Main-Class" to "org.springframework.boot.loader.PropertiesLauncher")
	}
}

4.4.6. 階層化された Jar または War のパッケージ化

デフォルトでは、bootJar タスクは、アプリケーションのクラスと依存関係をそれぞれ BOOT-INF/classes と BOOT-INF/lib に含むアーカイブを構築します。同様に、bootWar は、WEB-INF/classes のアプリケーションのクラスと、WEB-INF/lib および WEB-INF/lib-provided の依存関係を含むアーカイブを構築します。jar のコンテンツから docker イメージを作成する必要がある場合は、これらのディレクトリをさらに分離して、個別のレイヤーに書き込むことができると便利です。

階層化された jar は、通常の Boot パッケージ jar と同じレイアウトを使用しますが、各レイヤーを説明する追加のメタデータファイルが含まれています。

デフォルトでは、次のレイヤーが定義されています。

  • バージョンに SNAPSHOT が含まれていないプロジェクト以外の依存関係の dependencies。

  • jar ローダークラスの spring-boot-loader。

  • バージョンに SNAPSHOT が含まれているプロジェクト以外の依存関係の snapshot-dependencies。

  • プロジェクトの依存関係、アプリケーションクラス、リソース用の application。

レイヤーの順序は、アプリケーションの一部が変更されたときに前のレイヤーがキャッシュされる可能性を決定するため、重要です。デフォルトの順序は dependencies、spring-boot-loader、snapshot-dependencies、application です。変更の可能性が最も低いコンテンツを最初に追加し、次に変更の可能性が高いレイヤーを追加する必要があります。

この機能を無効にするには、次の方法で無効にします。

Groovy
bootJar {
	layered {
		enabled = false
	}
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	layered {
		isEnabled = false
	}
}

階層化された jar または war が作成されると、spring-boot-jarmode-layertools jar が依存関係としてアーカイブに追加されます。クラスパス上のこの jar を使用すると、特別なモードでアプリケーションを起動できます。これにより、ブートストラップコードで、アプリケーションとはまったく異なるもの（たとえば、レイヤーを抽出するもの）を実行できます。この依存関係を除外する場合は、次の方法で行うことができます。

Groovy
bootJar {
	layered {
		includeLayerTools = false
	}
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	layered {
		isIncludeLayerTools = false
	}
}
カスタムレイヤー構成

アプリケーションによっては、レイヤーの作成方法を調整し、新しいレイヤーを追加したい場合があります。

これは、jar または war をレイヤーに分離する方法と、それらのレイヤーの順序を説明する構成を使用して実行できます。次の例は、上記のデフォルトの順序を明示的に定義する方法を示しています。

Groovy
bootJar {
	layered {
		application {
			intoLayer("spring-boot-loader") {
				include "org/springframework/boot/loader/**"
			}
			intoLayer("application")
		}
		dependencies {
			intoLayer("application") {
				includeProjectDependencies()
			}
			intoLayer("snapshot-dependencies") {
				include "*:*:*SNAPSHOT"
			}
			intoLayer("dependencies")
		}
		layerOrder = ["dependencies", "spring-boot-loader", "snapshot-dependencies", "application"]
	}
}
Kotlin
tasks.getByName<BootJar>("bootJar") {
	layered {
		application {
			intoLayer("spring-boot-loader") {
				include("org/springframework/boot/loader/**")
			}
			intoLayer("application")
		}
		dependencies {
			intoLayer("snapshot-dependencies") {
				include("*:*:*SNAPSHOT")
			}
			intoLayer("dependencies")
		}
		layerOrder = listOf("dependencies", "spring-boot-loader", "snapshot-dependencies", "application")
	}
}

layered DSL は、3 つの部分を使用して定義されます。

  • application クロージャは、アプリケーションクラスとリソースを階層化する方法を定義します。

  • dependencies クロージャーは、依存関係を階層化する方法を定義します。

  • layerOrder メソッドは、レイヤーが書き込まれる順序を定義します。

ネストされた intoLayer クロージャーは、application および dependencies セクション内で使用され、レイヤーのコンテンツを要求します。これらのクロージャーは、定義された順序で上から下に評価されます。以前の intoLayer クロージャーによって要求されていないコンテンツは、引き続き後続のコンテンツで検討できます。

intoLayer クロージャーは、ネストされた include および exclude 呼び出しを使用してコンテンツを要求します。application クロージャーは、包含 / 除外パラメーターに Ant スタイルのパスマッチングを使用します。dependencies セクションは group:artifact[:version] パターンを使用します。また、プロジェクトの依存関係を含めたり除外したりするために使用できる includeProjectDependencies() および excludeProjectDependencies() メソッドも提供します。

include 呼び出しが行われない場合、すべてのコンテンツ（以前のクロージャーによって要求されていない）が考慮されます。

exclude 呼び出しが行われない場合、除外は適用されません。

上記の例の dependencies クロージャを見ると、最初の intoLayer が application レイヤーのすべてのプロジェクト依存関係を要求していることがわかります。次の intoLayer は、snapshot-dependencies レイヤーのすべての SNAPSHOT 依存関係を要求します。3 番目の最後の intoLayer は、dependencies レイヤーに残っているもの（この場合、プロジェクトの依存関係または SNAPSHOT ではない依存関係）を要求します。

application クロージャーにも同様のルールがあります。最初に、spring-boot-loader レイヤーの org/springframework/boot/loader/** コンテンツを要求します。次に、application レイヤーの残りのクラスとリソースを要求します。

intoLayer クロージャーが追加される順序は、多くの場合、レイヤーが書き込まれる順序とは異なります。このため、layerOrder メソッドは常に呼び出され、intoLayer 呼び出しによって参照されるすべてのレイヤーをカバーする必要があります。

5. OCI イメージのパッケージ化

プラグインは、Cloud Native Buildpacks (英語) （CNB）を使用して jar または war ファイルから OCI イメージ [GitHub] (英語) を作成できます。bootBuildImage タスクを使用してイメージを構築できます。

セキュリティ上の理由から、イメージは root 以外のユーザーとしてビルドおよび実行されます。詳細については、CNB 仕様 (英語) を参照してください。

タスクは、java または war プラグインが適用されると自動的に作成され、BootBuildImage (Javadoc) のインスタンスです。

5.1. Docker デーモン

bootBuildImage タスクは、Docker デーモンへのアクセスを必要とします。デフォルトでは、ローカル接続を介して Docker デーモンと通信します。これは、構成されていないすべてのサポートされているプラットフォーム上の Docker エンジン (英語) で動作します。

環境変数を設定して、minikube が提供する Docker デーモン (英語) を使用するように bootBuildImage タスクを構成できます。次の表は、環境変数とその値を示しています。

環境変数 説明

DOCKER_HOST

Docker デーモンのホストとポートを含む URL- 例: tcp://192.168.99.100:2376

DOCKER_TLS_VERIFY

1 に設定されている場合、安全な HTTPS プロトコルを有効にする (オプション)

DOCKER_CERT_PATH

HTTPS の証明書とキーファイルへのパス (DOCKER_TLS_VERIFY=1 の場合は必須、それ以外の場合は無視)

Linux および macOS では、これらの環境変数は、minikube の起動後にコマンド eval $(minikube docker-env) を使用して設定できます。

Docker デーモン接続情報は、プラグイン構成の docker プロパティを使用して提供することもできます。次の表は、使用可能なプロパティをまとめたものです。

プロパティ 説明

host

Docker デーモンのホストとポートを含む URL- 例: tcp://192.168.99.100:2376

tlsVerify

true に設定されている場合、安全な HTTPS プロトコルを有効にする (オプション)

certPath

HTTPS の証明書とキーファイルへのパス (tlsVerify が true の場合は必須、それ以外の場合は無視されます)

詳細については、例も参照してください。

5.2. Docker レジストリ

builder または runImage プロパティで指定された Docker イメージが、認証を必要とするプライベート Docker イメージレジストリに格納されている場合、認証資格情報は docker.builderRegistry プロパティを使用して提供できます。

生成された Docker イメージを Docker イメージレジストリに公開する場合は、docker.publishRegistry プロパティを使用して認証資格情報を提供できます。

プロパティは、ユーザー認証または ID トークン認証用に提供されています。サポートされている認証方法の詳細については、イメージの保存に使用されている Docker レジストリのドキュメントを参照してください。

次の表は、docker.builderRegistry および docker.publishRegistry で使用可能なプロパティをまとめたものです。

プロパティ 説明

username

Docker イメージレジストリユーザーのユーザー名。ユーザー認証に必要です。

password

Docker イメージレジストリユーザーのパスワード。ユーザー認証に必要です。

url

Docker イメージレジストリのアドレス。ユーザー認証のオプション。

email

Docker イメージレジストリユーザーのメールアドレス。ユーザー認証のオプション。

token

Docker イメージレジストリユーザーの ID トークン。トークン認証に必要です。

詳細については、例も参照してください。

5.3. イメージのカスタマイズ

プラグインはビルダー (英語) を呼び出して、イメージの生成を調整します。ビルダーには、生成されたイメージに影響を与えるためにアプリケーションをインスペクションできる複数の buildpacks が含 (英語) まれています。デフォルトでは、プラグインはビルダーイメージを選択します。生成されたイメージの名前は、プロジェクトのプロパティから推測されます。

タスクプロパティを使用して、ビルダーがプロジェクトでどのように動作するかを構成できます。次の表は、使用可能なプロパティとそのデフォルト値をまとめたものです。

プロパティ コマンドラインオプション 説明 デフォルト値

builder

--builder

使用する Builder イメージの名前。

paketobuildpacks/builder:base

runImage

--runImage

使用する実行イメージの名前。

デフォルト値はなく、Builder メタデータで指定された実行イメージを使用する必要があることを示します。

imageName

--imageName

生成されたイメージのイメージ名: (Javadoc) 。

docker.io/library/${project.name}:${project.version}

pullPolicy

--pullPolicy

ポリシー (Javadoc) は、ビルダーをプルしてレジストリからイメージを実行するタイミングを決定するために使用されます。許容値は ALWAYS、NEVER、IF_NOT_PRESENT です。

ALWAYS

environment

ビルダーに渡す必要のある環境変数。

buildpacks

ビルダーがイメージをビルドするときに使用する必要がある Buildpacks。指定された buildpacks のみが使用され、ビルダーに含まれているデフォルトの buildpacks がオーバーライドされます。Buildpack 参照は、次のいずれかの形式である必要があります。

  • ビルダーの Buildpack - [urn:cnb:builder:]<buildpack ID>[@<version>]

  • ファイルシステム上のディレクトリ内の Buildpack- [file://]<path>

  • ファイルシステム上の gzip 圧縮された tar（.tgz）ファイル内の Buildpack- [file://]<path>/<file name>

  • OCI イメージの Buildpack- [docker://]<host>/<repo>[:<tag>][@<digest>]

なし。ビルダーがそれに含まれる buildpacks を使用する必要があることを示します。

bindings

イメージをビルドするときにビルダーコンテナーにマウントする必要があるボリュームバインドマウント (英語) 。バインディングは、ビルダーコンテナーの作成時に、解析されず、検証されずに Docker に渡されます。バインディングは、次のいずれかの形式である必要があります。

  • <host source path>:<container destination path>[:<options>]

  • <host volume name>:<container destination path>[:<options>]

<options> に含めることができる場所:

  • ボリュームを読み取り専用としてコンテナーにマウントする ro 

  • ボリュームをコンテナー内で読み取り可能および書き込み可能としてマウントするための rw 

  • オプション名とその値で構成されるキーと値のペアを指定する volume-opt=key=value 

network

--network

ビルダーコンテナーが使用するように構成されたネットワークドライバー (英語) 。指定された値は、ビルダーコンテナーの作成時に、検証されずに Docker に渡されます。

cleanCache

--cleanCache

構築する前にキャッシュを消去するかどうか。

false

verboseLogging

ビルダー操作の詳細ログを有効にします。

false

publish

--publishImage

生成されたイメージを Docker レジストリに公開するかどうか。

false

tags

生成されたイメージに適用する 1 つ以上の追加タグのリスト。

buildCache

buildpacks によって作成され、イメージ構築プロセスによって使用されるレイヤーを含むキャッシュ。

イメージ名から派生した名前を持つ、Docker デーモン内の名前付きボリューム。

launchCache

buildpacks によって作成され、イメージ起動プロセスによって使用されるレイヤーを含むキャッシュ。

イメージ名から派生した名前を持つ、Docker デーモン内の名前付きボリューム。

プラグインは、JavaPlugin の targetCompatibility プロパティを使用して、プロジェクトのターゲット Java 互換性を検出します。デフォルトの Paketo ビルダーと buildpacks を使用する場合、プラグインは buildpacks に同じ Java バージョンをインストールするように指示します。ビルダーの構成例に示されているように、この動作をオーバーライドできます。

5.4. サンプル

5.4.1. カスタムイメージビルダーと実行イメージ

イメージの作成に使用されるビルダーまたはビルドされたイメージの起動に使用される実行イメージをカスタマイズする必要がある場合は、次の例に示すようにタスクを構成します。

Groovy
bootBuildImage {
	builder = "mine/java-cnb-builder"
	runImage = "mine/java-cnb-run"
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	builder = "mine/java-cnb-builder"
	runImage = "mine/java-cnb-run"
}

この構成では、名前 mine/java-cnb-builder およびタグ latest のビルダーイメージ、および mine/java-cnb-run という名前の実行イメージとタグ latest を使用します。

この例に示すように、ビルダーと実行イメージはコマンドラインでも指定できます。

$ gradle bootBuildImage --builder=mine/java-cnb-builder --runImage=mine/java-cnb-run

5.4.2. ビルダー構成

ビルダーが構成オプションを公開する場合、environment プロパティを使用して設定できます。

以下は、ビルド時に Paketo Java buildpacks によって使用される JVM バージョンを構成する例 (英語) です。

Groovy
bootBuildImage {
	environment = ["BP_JVM_VERSION" : "8.*"]
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	environment = mapOf("BP_JVM_VERSION" to "8.*")
}

ビルダーが実行されている Docker デーモンと buildpacks がアーティファクトをダウンロードするネットワークの場所の間にネットワークプロキシがある場合は、プロキシを使用するようにビルダーを構成する必要があります。Paketo ビルダーを使用する場合、これは、次の例に示すように、HTTPS_PROXY および / または HTTP_PROXY 環境変数を設定することで実現できます。

Groovy
bootBuildImage {
	environment = [
			"HTTP_PROXY" : "http://proxy.example.com",
			"HTTPS_PROXY": "https://proxy.example.com"
	]
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	environment = mapOf("HTTP_PROXY" to "http://proxy.example.com",
						"HTTPS_PROXY" to "https://proxy.example.com")
}

5.4.3. ランタイム JVM 構成

Paketo Java buildpacks は、JAVA_TOOL_OPTIONS 環境変数を設定することにより、JVM ランタイム環境を構成 (英語) します。ビルドパックが提供する JAVA_TOOL_OPTIONS 値を変更して、アプリケーションイメージがコンテナーで起動されたときの JVM ランタイムの動作をカスタマイズできます。

イメージに保存してすべてのデプロイに適用する必要がある環境変数の変更は、Paketo ドキュメント (英語) に従って設定でき、次の例に示されています。

Groovy
bootBuildImage {
	environment = [
			"BPE_DELIM_JAVA_TOOL_OPTIONS" : " ",
			"BPE_APPEND_JAVA_TOOL_OPTIONS" : "-XX:+HeapDumpOnOutOfMemoryError"
	]
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	environment = mapOf(
		"BPE_DELIM_JAVA_TOOL_OPTIONS" to " ",
		"BPE_APPEND_JAVA_TOOL_OPTIONS" to "-XX:+HeapDumpOnOutOfMemoryError"
	)
}

5.4.4. カスタムイメージ名

デフォルトでは、イメージ名は name および docker.io/library/${project.name}:${project.version} のようなプロジェクトの version から推測されます。次の例に示すように、タスクのプロパティを設定することにより、名前を制御できます。

Groovy
bootBuildImage {
	imageName = "example.com/library/${project.name}"
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	imageName = "example.com/library/${project.name}"
}

この構成では明示的なタグが提供されないため、latest が使用されることに注意してください。${project.version}、ビルドで使用可能なプロパティ、ハードコードされたバージョンのいずれかを使用して、タグを指定することもできます。

次の例に示すように、イメージ名はコマンドラインでも指定できます。

$ gradle bootBuildImage --imageName=example.com/library/my-app:v1

5.4.5. Buildpacks

デフォルトでは、ビルダーはビルダーイメージに含まれている buildpacks を使用し、事前定義された順序で適用します。buildpacks の代替セットを提供して、ビルダーに含まれていない buildpacks を適用したり、含まれている buildpacks の順序を変更したりできます。1 つ以上の buildpacks が提供されている場合、指定された buildpacks のみが適用されます。

次の例では、.tgz ファイルにパッケージ化されたカスタム buildpack を使用し、その後にビルダーに含まれる buildpack を使用するようにビルダーに指示します。

Groovy
bootBuildImage {
	buildpacks = ["file:///path/to/example-buildpack.tgz", "urn:cnb:builder:paketo-buildpacks/java"]
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	buildpacks = listOf("file:///path/to/example-buildpack.tgz", "urn:cnb:builder:paketo-buildpacks/java")
}

Buildpacks は、以下に示す任意の形式で指定できます。

CNB ビルダーにある buildpack（ビルダーに buildpack-id に一致する buildpack が 1 つしかない場合は、バージョンを省略できます）:

buildpack コンテンツを含むディレクトリへのパス（Windows ではサポートされていません）:

  • file:///path/to/buildpack/

  • /path/to/buildpack/

buildpack コンテンツを含む gzip 圧縮された tar ファイルへのパス:

  • file:///path/to/buildpack.tgz

  • /path/to/buildpack.tgz

パッケージ化された buildpack (英語) を含む OCI イメージ:

  • docker://example/buildpack

  • docker:///example/buildpack:latest

  • docker:///example/buildpack@sha256:45b23dee08…​

  • example/buildpack

  • example/buildpack:latest

  • example/buildpack@sha256:45b23dee08…​

5.4.6. イメージ公開

生成されたイメージは、publish オプションを有効にし、docker.publishRegistry プロパティを使用してレジストリの認証を構成することにより、Docker レジストリに公開できます。

Groovy
bootBuildImage {
	imageName = "docker.example.com/library/${project.name}"
	publish = true
	docker {
		publishRegistry {
			username = "user"
			password = "secret"
			url = "https://docker.example.com/v1/"
			email = "[email protected] (英語)  "
		}
	}
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	imageName = "docker.example.com/library/${project.name}"
	isPublish = true
	docker {
		publishRegistry {
			username = "user"
			password = "secret"
			url = "https://docker.example.com/v1/"
			email = "[email protected] (英語)  "
		}
	}
}

この例に示すように、publish オプションはコマンドラインでも指定できます。

$ gradle bootBuildImage --imageName=docker.example.com/library/my-app:v1 --publishImage

5.4.7. Builder キャッシュ構成

CNB ビルダーは、イメージのビルドおよび起動時に使用されるレイヤーをキャッシュします。デフォルトでは、これらのキャッシュは、ターゲットイメージのフルネームから派生した名前で Docker デーモンに名前付きボリュームとして保存されます。プロジェクトのバージョンがイメージ名のタグとして使用されている場合など、イメージ名が頻繁に変更される場合、キャッシュが頻繁に無効化される可能性があります。

次の例に示すように、キャッシュボリュームは、代替名を使用してキャッシュライフサイクルをより細かく制御できるように構成できます。

Groovy
bootBuildImage {
	buildCache {
		volume {
			name = "cache-${rootProject.name}.build"
		}
	}
	launchCache {
		volume {
			name = "cache-${rootProject.name}.launch"
		}
	}
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	buildCache {
		volume {
			name = "cache-${rootProject.name}.build"
		}
	}
	launchCache {
		volume {
			name = "cache-${rootProject.name}.launch"
		}
	}
}

5.4.8. Docker の設定

デフォルトのローカル接続の代わりにリモート接続を使用して Docker デーモンと通信するプラグインが必要な場合は、次の例に示すように、docker プロパティを使用して接続の詳細を提供できます。

Groovy
bootBuildImage {
	docker {
		host = "tcp://192.168.99.100:2376"
		tlsVerify = true
		certPath = "/home/users/.minikube/certs"
	}
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	docker {
		host = "tcp://192.168.99.100:2376"
		isTlsVerify = true
		certPath = "/home/users/.minikube/certs"
	}
}

ビルダーまたは実行イメージがユーザー認証をサポートするプライベート Docker レジストリに保管されている場合、次の例に示すように、docker.builderRegistry プロパティを使用して認証の詳細を提供できます。

Groovy
bootBuildImage {
	docker {
		builderRegistry {
			username = "user"
			password = "secret"
			url = "https://docker.example.com/v1/"
			email = "[email protected] (英語)  "
		}
	}
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	docker {
		builderRegistry {
			username = "user"
			password = "secret"
			url = "https://docker.example.com/v1/"
			email = "[email protected] (英語)  "
		}
	}
}

ビルダーまたは実行イメージがトークン認証をサポートするプライベート Docker レジストリに保管されている場合、次の例に示すように、docker.builderRegistry を使用してトークン値を提供できます。

Groovy
bootBuildImage {
	docker {
		builderRegistry {
			token = "9cbaf023786cd7..."
		}
	}
}
Kotlin
tasks.getByName<BootBuildImage>("bootBuildImage") {
	docker {
		builderRegistry {
			token = "9cbaf023786cd7..."
		}
	}
}

6. アプリケーションの公開

6.1. Maven-publish プラグインを使用した公開

Spring Boot jar または war を公開するには、MavenPublication で artifact メソッドを使用して公開に追加します。公開するアーティファクトを生成するタスクを artifact メソッドに渡します。例: デフォルトの bootJar タスクによって生成されたアーティファクトを公開するには:

Groovy
publishing {
	publications {
		bootJava(MavenPublication) {
			artifact bootJar
		}
	}
	repositories {
		maven {
			url 'https://repo.example.com'
		}
	}
}
Kotlin
publishing {
	publications {
		create<MavenPublication>("bootJava") {
			artifact(tasks.getByName("bootJar"))
		}
	}
	repositories {
		maven {
			url = uri("https://repo.example.com")
		}
	}
}

6.2. Maven プラグインで公開する

Gradle 6 での非推奨のため、Gradle の maven プラグインでの公開に対するこのプラグインのサポートは非推奨になり、将来のリリースで削除される予定です。代わりに maven-publish プラグインを使用してください。

maven プラグイン (英語) が適用されると、uploadBootArchives という名前の bootArchives 構成の Upload タスクが自動的に作成されます。デフォルトでは、bootArchives 構成には、bootJar または bootWar タスクによって作成されたアーカイブが含まれています。uploadBootArchives タスクは、アーカイブを Maven リポジトリに公開するように構成できます。

Groovy
uploadBootArchives {
	repositories {
		mavenDeployer {
			repository url: 'https://repo.example.com'
		}
	}
}
Kotlin
tasks.getByName<Upload>("uploadBootArchives") {
	repositories.withGroovyBuilder {
		"mavenDeployer" {
			"repository"("url" to "https://repo.example.com")
		}
	}
}

6.3. アプリケーションプラグインを使用した配布

application プラグイン (英語) が適用されると、boot という名前のディストリビューションが作成されます。このディストリビューションには、bootJar または bootWar タスクによって生成されたアーカイブと、それを Unix 系プラットフォームおよび Windows 上で起動するためのスクリプトが含まれています。Zip ディストリビューションと tar ディストリビューションは、それぞれ bootDistZip タスクと bootDistTar タスクによって構築できます。application プラグインを使用するには、その mainClassName プロパティをアプリケーションのメインクラスの名前で構成する必要があります。

7. Gradle でアプリケーションを実行する

アーカイブを作成せずにアプリケーションを実行するには、bootRun タスクを使用します。

$ ./gradlew bootRun

bootRun タスクは、JavaExec サブクラスである BootRun (Javadoc) のインスタンスです。そのため、Gradle で Java プロセスを実行するための通常の構成オプション (英語) はすべて利用可能です。タスクは、メインソースセットのランタイムクラスパスを使用するように自動的に構成されます。

デフォルトでは、メインクラスは、タスクのクラスパス上のディレクトリで public static void main(String[]) メソッドを持つクラスを探すことで自動的に構成されます。

メインクラスは、タスクの main プロパティを使用して明示的に構成することもできます。

Groovy
bootRun {
	main = 'com.example.ExampleApplication'
}
Kotlin
tasks.getByName<BootRun>("bootRun") {
	main = "com.example.ExampleApplication"
}

または、Spring Boot DSL の mainClass プロパティを使用して、プロジェクト全体でメインクラス名を設定できます。

Groovy
springBoot {
	mainClass = 'com.example.ExampleApplication'
}
Kotlin
springBoot {
	mainClass.set("com.example.ExampleApplication")
}

デフォルトでは、bootRun は JVM を構成して、開発中の起動を高速化するために最適化します。この動作は、次の例に示すように、optimizedLaunch プロパティを使用して無効にすることができます。

Groovy
bootRun {
	optimizedLaunch = false
}
Kotlin
tasks.getByName<BootRun>("bootRun") {
	isOptimizedLaunch = false
}

application プラグイン (英語) が適用されている場合は、その mainClass のプロパティが設定されている必要があり、同じ目的で使用することができます。

Groovy
application {
	mainClass = 'com.example.ExampleApplication'
}
Kotlin
application {
	mainClass.set("com.example.ExampleApplication")
}

7.1. アプリケーションに引数を渡す

すべての JavaExec タスクと同様に、Gradle 4.9 以降を使用する場合は、--args='<arguments>' を使用してコマンドラインから引数を bootRun に渡すことができます。例: dev という名前のプロファイルをアクティブにしてアプリケーションを実行するには、次のコマンドを使用できます。

$ ./gradlew bootRun --args='--spring.profiles.active=dev'

詳細については、JavaExec.setArgsString の javadoc を参照して (英語) ください。

7.2. システムプロパティをアプリケーションに渡す

bootRun は標準の JavaExec タスクであるため、ビルドスクリプトで指定することにより、システムプロパティをアプリケーションの JVM に渡すことができます。システムプロパティのその値を構成可能にするには、プロジェクトプロパティ (英語) を使用してその値を設定します。プロジェクトプロパティをオプションにするには、findProperty を使用して参照します。これにより、次の例に示すように、?: エルビス演算子を使用してデフォルト値を提供することもできます。

Groovy
bootRun {
	systemProperty 'com.example.property', findProperty('example') ?: 'default'
}
Kotlin
tasks.getByName<BootRun>("bootRun") {
	systemProperty("com.example.property", findProperty("example") ?: "default")
}

上記の例では、その com.example.property システムプロパティを example プロジェクトプロパティの値に設定しています。example プロジェクトプロパティが設定されていない場合、システムプロパティの値は default になります。

Gradle を使用すると、次の例に示すように、-P フラグを使用したコマンドラインなど、さまざまな方法でプロジェクトプロパティを設定できます。

$ ./gradlew bootRun -Pexample=custom

上記の例では、example プロジェクトプロパティの値を custom に設定しています。bootRun は、これを com.example.property システムプロパティの値として使用します。

7.3. リソースの再読み込み

プロジェクトに devtools が追加されている場合、アプリケーションの変更を自動的に監視します。または、bootRun を構成して、アプリケーションの静的リソースがソースの場所からロードされるようにすることができます。

Groovy
bootRun {
	sourceResources sourceSets.main
}
Kotlin
tasks.getByName<BootRun>("bootRun") {
	sourceResources(sourceSets["main"])
}

これにより、開発中に役立つ可能性があるライブアプリケーションに再読み込み可能になります。

8. アクチュエーターとの統合

8.1. ビルド情報の生成

Spring Boot Actuator の info エンドポイントは、META-INF/build-info.properties ファイルの存在下でビルドに関する情報を自動的に公開します。このファイルを生成するために、BuildInfo (Javadoc) タスクが提供されています。タスクを使用する最も簡単な方法は、プラグインの DSL を使用することです。

Groovy
springBoot {
	buildInfo()
}
Kotlin
springBoot {
	buildInfo()
}

これにより、bootBuildInfo という名前の BuildInfo (Javadoc) タスクが構成され、存在する場合は、Java プラグインの classes タスクがそれに依存するようになります。タスクの宛先ディレクトリは、メインソースセットのリソースの出力ディレクトリにある META-INF （通常は build/resources/main）です。

デフォルトでは、生成されたビルド情報はプロジェクトから取得されます。

プロパティ デフォルト値

build.artifact

bootJar または bootWar タスクのベース名

build.group

プロジェクトのグループ

build.name

プロジェクトの名前

build.version

プロジェクトのバージョン

build.time

プロジェクトが構築されている時間

プロパティは、DSL を使用してカスタマイズできます。

Groovy
springBoot {
	buildInfo {
		properties {
			artifact = 'example-app'
			version = '1.2.3'
			group = 'com.example'
			name = 'Example application'
		}
	}
}
Kotlin
springBoot {
	buildInfo {
		properties {
			artifact = "example-app"
			version = "1.2.3"
			group = "com.example"
			name = "Example application"
		}
	}
}
生成されたビルド情報からデフォルトのプロパティを省略するには、その値を null に設定します。

build.time のデフォルト値は、プロジェクトがビルドされる瞬間です。これの副作用は、タスクが最新にならないことです。その結果、プロジェクトのテストなど、より多くのタスクを実行する必要があるため、ビルドに時間がかかります。もう 1 つの副作用は、タスクの出力が常に変更されるため、ビルドが実際に再現できないことです。build.time プロパティの精度よりもビルドパフォーマンスまたは再現性を高く評価する場合は、time を null または固定値に設定します。

追加のプロパティをビルド情報に追加することもできます。

Groovy
springBoot {
	buildInfo {
		properties {
			additional = [
				'a': 'alpha',
				'b': 'bravo'
			]
		}
	}
}
Kotlin
springBoot {
	buildInfo {
		properties {
			additional = mapOf(
				"a" to "alpha",
				"b" to "bravo"
			)
		}
	}
}

9. 他のプラグインへの反応

別のプラグインが適用されると、Spring Boot プラグインはプロジェクトの構成にさまざまな変更を加えることで反応します。このセクションでは、これらの変更について説明します。

9.1. Java プラグインへの反応

Gradle の java プラグイン (英語) がプロジェクトに適用されると、Spring Boot プラグインは次のようになります。

  1. プロジェクトの実行可能ファイル fat jar を作成する bootJar という名前の BootJar (Javadoc) タスクを作成します。jar には、メインソースセットのランタイムクラスパス上のすべてが含まれます。クラスは BOOT-INF/classes にパッケージ化され、jar は BOOT-INF/lib にパッケージ化されます

  2. bootJar タスクに依存するように assemble タスクを構成します。

  3. plain をアーカイブ分類子の規則として使用するように jar タスクを構成します。

  4. buildpack (英語) を使用して OCI イメージを作成する bootBuildImage という名前の BootBuildImage (Javadoc) タスクを作成します。

  5. アプリケーションの実行に使用できる bootRun という名前の BootRun (Javadoc) タスクを作成します。

  6. bootJar タスクによって生成された成果物を含む bootArchives という名前の構成を作成します。

  7. Spring Boot Boot の Devtools のように、開発時にのみ必要で、実行可能な jar や war にパッケージされるべきではない依存関係のために、developmentOnly という名前の設定を作成します。

  8. productionRuntimeClasspath という名前の構成を作成します。これは、runtimeClasspath から developmentOnly 構成にのみ表示される依存関係を除いたものと同等です。

  9. エンコーディングが構成されていない JavaCompile タスクが UTF-8 を使用するように構成します。

  10. -parameters コンパイラー引数を使用するように JavaCompile タスクを構成します。

9.2. Kotlin プラグインへの反応

Kotlin の Gradle プラグイン (英語) がプロジェクトに適用されると、Spring Boot プラグインは次のことを行います。

  1. Spring Boot の依存関係管理で使用される Kotlin バージョンをプラグインのバージョンに合わせます。これは、Kotlin プラグインのバージョンに一致する値で kotlin.version プロパティを設定することにより実現されます。

  2. -java-parameters コンパイラー引数を使用するように KotlinCompile タスクを構成します。

9.3. War プラグインへの反応

Gradle の war プラグイン (英語) がプロジェクトに適用されると、Spring Boot プラグインは次のようになります。

  1. プロジェクトの実行可能な fat war を作成する bootWar という名前の BootWar (Javadoc) タスクを作成します。標準パッケージに加えて、providedRuntime 構成のすべてが WEB-INF/lib-provided にパッケージされます。

  2. bootWar タスクに依存するように assemble タスクを構成します。

  3. plain をアーカイブ分類子の規則として使用するように war タスクを構成します。

  4. bootArchives 構成を構成して、bootWar タスクによって生成された成果物を含めます。

9.4. 依存関係管理プラグインへの対応

io.spring.dependency-management プラグイン [GitHub] (英語) がプロジェクトに適用されると、Spring Boot プラグインは spring-boot-dependencies bom を自動的にインポートします。

9.5. アプリケーションプラグインへの反応

Gradle の application プラグイン (英語) がプロジェクトに適用されると、Spring Boot プラグインは次のようになります。

  1. java -jar を使用して bootArchives 構成でアーティファクトを起動するスクリプトを作成する bootStartScripts という名前の CreateStartScripts タスクを作成します。タスクは、defaultJvmOpts プロパティの規則として applicationDefaultJvmArgs プロパティを使用するように構成されています。

  2. boot という名前の新しいディストリビューションを作成し、lib ディレクトリの bootArchives 構成のアーティファクトと bin ディレクトリの開始スクリプトを含むように構成します。

  3. main プロパティの規則として mainClassName プロパティを使用するように bootRun タスクを構成します。

  4. jvmArgs プロパティの規則として applicationDefaultJvmArgs プロパティを使用するように bootRun タスクを構成します。

  5. マニフェストの Start-Class エントリの規則として mainClassName プロパティを使用するように bootJar タスクを構成します。

  6. マニフェストの Start-Class エントリの規則として mainClassName プロパティを使用するように bootWar タスクを構成します。

9.6. Maven プラグインへの反応

Gradle の maven プラグインへの対応のサポートは廃止され、将来のリリースで削除される予定です。代わりに maven-publish プラグインを使用してください。

Gradle の maven プラグイン (英語) がプロジェクトに適用されると、Spring Boot プラグインは uploadBootArchivesUpload タスクを構成して、生成する pom で依存関係が宣言されないようにします。