1. 導入

Spring Boot Gradle プラグインは、Gradle (英語) で Spring Boot サポートを提供します。実行可能な jar または war アーカイブをパッケージ化し、Spring Boot アプリケーションを実行し、spring-boot-dependencies によって提供される依存関係管理を使用できます。Spring Boot の Gradle プラグインには Gradle 6(6.3 以降)が必要です。Gradle 5.6 もサポートされていますが、このサポートは推奨されておらず、将来のリリースで削除される予定です。

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

2. 入門

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

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

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

プラグインを単独で適用すると、プロジェクトにいくつかの変更が加えられます。代わりに、プラグインは他の特定のプラグインが適用されたときにそれを検出し、それに応じて反応します。例: 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.3.3.RELEASE"
}

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

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

3. 依存関係の管理

Spring Boot アプリケーションの依存関係を管理するには、io.spring.dependency-management (GitHub) プラグインを適用するか、Gradle 6 以降を使用している場合は 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.3.3.RELEASE' apply false
}
Kotlin
plugins {
	id("org.springframework.boot") version "2.3.3.RELEASE" 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.3.3.RELEASE" apply false
	id("io.spring.dependency-management") version "1.0.10.RELEASE"
}

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

3.1.3. さらに学ぶ

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

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 タスクは無効になっています。jar または war タスクを有効にすることにより、実行可能なアーカイブと通常のアーカイブの両方を同時にビルドするようにプロジェクトを構成できます。

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

実行可能アーカイブと通常のアーカイブが同じ場所に書き込まれないようにするには、どちらか一方を別の場所を使用するように構成する必要があります。そのための 1 つの方法は、分類子を構成することです。

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

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

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

4.4.1. メインクラスの構成

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

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

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

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

Groovy
springBoot {
	mainClassName = 'com.example.ExampleApplication'
}
Kotlin
springBoot {
	mainClassName = "com.example.ExampleApplication"
}

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

Groovy
mainClassName = 'com.example.ExampleApplication'
Kotlin
application {
	mainClassName = "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")
	}
}

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 で実行したり、サーブレットコンテナーにデプロイしたり、OCI イメージに組み込んだりするのではなく、直接実行する場合にのみ有効にすることをお勧めします。

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

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 のパッケージング

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

レイヤード jar は、通常のブートパッケージ jar と同じレイアウトを使用しますが、各レイヤーを説明する追加のメタデータファイルを含みます。この機能を使用するには、レイヤー機能を有効にする必要があります。

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

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

  • dependencies (バージョンに SNAPSHOT を含まない依存関係の場合)。

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

  • バージョンに SNAPSHOT が含まれる依存関係の snapshot-dependencies

  • アプリケーションクラスとリソースの application

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

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

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

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

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

Groovy
bootJar {
	layered {
		application {
			intoLayer("spring-boot-loader") {
				include "org/springframework/boot/loader/**"
			}
			intoLayer("application")
		}
		dependencies {
			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] パターンを使用します。

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

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

上記の例の dependencies クロージャーを見ると、最初の intoLayer が snapshot-dependencies レイヤーのすべての SNAPSHOT 依存関係を要求していることがわかります。後続の intoLayer は、dependencies レイヤーに残っているもの(この場合は、スナップショットではない依存関係)を要求します。

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

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

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

プラグインは、クラウドネイティブビルドパック (英語) を使用して実行可能な jar から OCI イメージ (GitHub) を作成できます。bootBuildImage タスクを使用してイメージを構築できます。タスクは、java プラグインが適用されたときに自動的に作成され、BootBuildImage(Javadoc) のインスタンスです。

bootBuildImage タスクは、起動スクリプトを含む完全に実行可能な Spring Boot アーカイブでは使用できません。bootBuildImage で使用することを目的とした jar ファイルをビルドするときは、bootJar タスクの起動スクリプト構成を無効にします。

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) を使用して設定できます。

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

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

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

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

builder

--builder

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

gcr.io/paketo-buildpacks/builder:base-platform-api-0.3

runImage

--runImage

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

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

imageName

--imageName

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

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

environment

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

cleanCache

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

false

verboseLogging

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

false

5.3. サンプル

5.3.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.3.2. ビルダー構成

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

次の例では、デフォルトのビルダーが BP_JVM_VERSION プロパティを認識することを前提としています。このプロパティは通常、メジャーバージョンと残りのバージョンのワイルドカードを指定して、イメージが使用する JDK バージョンをカスタマイズするために使用されます。

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

ビルダーが実行される Docker デーモンと、ビルドパックをダウンロードするアーティファクトのネットワークロケーションの間にネットワークプロキシがある場合は、プロキシを使用するようにビルダーを設定する必要があります。デフォルトのビルダーを使用する場合、次の例に示すように、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.3.3. カスタムイメージ名

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

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

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

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

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

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

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

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.2. 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.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 の mainClassName プロパティを使用して、プロジェクト全体でメインクラス名を設定できます。

Groovy
springBoot {
	mainClassName = 'com.example.ExampleApplication'
}
Kotlin
springBoot {
	mainClassName = "com.example.ExampleApplication"
}

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

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

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

Groovy
application {
	mainClassName = 'com.example.ExampleApplication'
}
Kotlin
application {
	mainClassName = "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 に渡すことができます。値はパラメーター化し、-P フラグを使用してコマンドラインでプロパティとして渡すことができます。

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 タスクのベース名、またはそのようなタスクが存在しない場合は unspecified 

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"
		}
	}
}

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. jar タスクを無効にします。

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

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

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

  7. Spring Boot の Devtools など、開発時にのみ必要な依存関係のために developmentOnly という名前の構成を作成し、実行可能 jar および war にパッケージ化しないでください。

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

  9. -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. 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 プラグイン (英語) がプロジェクトに適用されると、Spring Boot プラグインは uploadBootArchivesUpload タスクを構成して、生成する pom で依存関係が宣言されないようにします。

Unofficial Translation by spring.pleiades.io. See the original content.