The Spring Boot Gradle Plugin provides Spring Boot support in https://gradle.org[Gradle].
It allows you to package executable jar or war archives, run Spring Boot applications, and use the dependency management provided by `spring-boot-dependencies`.
Spring Boot's Gradle plugin requires Gradle 6 (6.3 or later).
Spring Boot Actuator's `info` endpoint automatically publishes information about your build in the presence of a `META-INF/build-info.properties` file.
A {build-info-javadoc}[`BuildInfo`] task is provided to generate this file.
The easiest way to use the task is via the plugin's DSL:
When you apply the {dependency-management-plugin}[`io.spring.dependency-management`] plugin, Spring Boot's plugin will automatically <<reacting-to-other-plugins-dependency-management,import the `spring-boot-dependencies` bom>> from the version of Spring Boot that you are using.
This provides a similar dependency management experience to the one that's enjoyed by Maven users.
For example, it allows you to omit version numbers when declaring dependencies that are managed in the bom.
The `spring-boot-dependencies` bom that is automatically imported when the dependency management plugin is applied uses properties to control the versions of the dependencies that it manages.
Browse the {version-properties-appendix}[`Dependency versions Appendix`] in the Spring Boot reference for a complete list of these properties.
To learn more about the capabilities of the dependency management plugin, please refer to its {dependency-management-plugin-documentation}[documentation].
The plugin can create an https://github.com/opencontainers/image-spec[OCI image] from executable jars using https://buildpacks.io[Cloud Native Buildpacks].
Images can be built using the `bootBuildImage` task.
The task is automatically created when the `java` plugin is applied and is an instance of {boot-build-image-javadoc}[`BootBuildImage`].
@ -7,7 +7,7 @@ The task is automatically created when the `java` plugin is applied and is an in
[[build-image-docker-daemon]]
=== Docker daemon
=== Docker Daemon
The `bootBuildImage` task requires access to a Docker daemon.
By default, it will communicate with a Docker daemon over a local connection.
This works with https://docs.docker.com/install/[Docker Engine] on all supported platforms without configuration.
@ -33,7 +33,7 @@ On Linux and macOS, these environment variables can be set using the command `ev
[[build-image-customization]]
=== Image customizations
=== Image Customizations
The plugin invokes a {buildpacks-reference}/concepts/components/builder/[builder] to orchestrate the generation of an image.
The builder includes multiple {buildpacks-reference}/concepts/components/buildpack[buildpacks] that can inspect the application to influence the generated image.
By default, the plugin chooses a builder image.
@ -79,7 +79,7 @@ The following table summarizes the available properties and their default values
[[build-image-example-custom-image-builder]]
==== Custom image builder
==== Custom Image Builder
If you need to customize the builder used to create the image, configure the task as shown in the following example:
@ -99,8 +99,7 @@ This configuration will use a builder image with the name `mine/java-cnb-builder
[[build-image-example-builder-configuration]]
==== Builder configuration
==== Builder Configuration
If the builder exposes configuration options, those can be set using the `environment` property.
The following example assumes that the default builder defines a `BP_JAVA_VERSION` property (typically used to customize the JDK version the image should use):
By default, the image name is inferred from the `artifactId` and the `version` of the project, something like `docker.io/library/${project.artifactId}:${project.version}`.
You can take control over the name by setting task properties, as shown in the following example:
The plugin can create executable archives (jar files and war files) that contain all of an application's dependencies and can then be run with `java -jar`.
[[packaging-executable-jars]]
=== Packaging executable jars
=== Packaging Executable Jars
Executable jars can be built using the `bootJar` task.
The task is automatically created when the `java` plugin is applied and is an instance of {boot-jar-javadoc}[`BootJar`].
The `assemble` task is automatically configured to depend upon the `bootJar` task so running `assemble` (or `build`) will also run the `bootJar` task.
@ -13,7 +13,7 @@ The `assemble` task is automatically configured to depend upon the `bootJar` tas
[[packaging-executable-wars]]
=== Packaging executable wars
=== Packaging Executable Wars
Executable wars can be built using the `bootWar` task.
The task is automatically created when the `war` plugin is applied and is an instance of {boot-war-javadoc}[`BootWar`].
The `assemble` task is automatically configured to depend upon the `bootWar` task so running `assemble` (or `build`) will also run the `bootWar` task.
@ -21,7 +21,7 @@ The `assemble` task is automatically configured to depend upon the `bootWar` tas
[[packaging-executable-wars-deployable]]
==== Packaging executable and deployable wars
==== Packaging Executable and Deployable Wars
A war file can be packaged such that it can be executed using `java -jar` and deployed to an external container.
To do so, the embedded servlet container dependencies should be added to the `providedRuntime` configuration, for example:
@ -45,7 +45,7 @@ NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as,
[[packaging-executable-and-normal]]
=== Packaging executable and normal archives
=== Packaging Executable and Normal Archives
By default, when the `bootJar` or `bootWar` tasks are configured, the `jar` or `war` tasks are disabled.
A project can be configured to build both an executable archive and a normal archive at the same time by enabling the `jar` or `war` task:
The {boot-jar-javadoc}[`BootJar`] and {boot-war-javadoc}[`BootWar`] tasks are subclasses of Gradle's `Jar` and `War` tasks respectively.
As a result, all of the standard configuration options that are available when packaging a jar or war are also available when packaging an executable jar or war.
A number of configuration options that are specific to executable jars and wars are also provided.
[[packaging-executable-configuring-main-class]]
==== Configuring the main class
==== Configuring the Main Class
By default, the executable archive's main class will be configured automatically by looking for a class with a `public static void main(String[])` method in directories on the task's classpath.
The main class can also be configured explicitly using the task's `mainClassName` property:
By default, the `bootJar` task builds an archive that contains the application's classes and dependencies in `BOOT-INF/classes` and `BOOT-INF/lib` respectively.
For cases where a docker image needs to be built from the contents of the jar, it's useful to be able to separate these folders further so that they can be written into distinct layers.
When the {maven-plugin}[`maven` plugin] is applied, an `Upload` task for the `bootArchives` configuration named `uploadBootArchives` is automatically created.
By default, the `bootArchives` configuration contains the archive produced by the `bootJar` or `bootWar` task.
The `uploadBootArchives` task can be configured to publish the archive to a Maven repository:
When the {dependency-management-plugin}[`io.spring.dependency-management` plugin] is applied to a project, the Spring Boot plugin will automatically import the `spring-boot-dependencies` bom.
[[reacting-to-other-plugins-application]]
=== Reacting to the application plugin
=== Reacting to the Application Plugin
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the Spring Boot plugin:
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
While you may start your Spring Boot application very easily from your test (or test suite) itself, it may be desirable to handle that in the build itself.
To make sure that the lifecycle of your Spring Boot application is properly managed around your integration tests, you can use the `start` and `stop` goals, as shown in the following example:
The plugin can create an https://github.com/opencontainers/image-spec[OCI image] using https://buildpacks.io/[Cloud Native Buildpacks].
Images can be built using the `build-image` goal.
@ -32,7 +32,7 @@ When the `build-image` repackages the application, it applies the same settings
[[build-image-docker-daemon]]
=== Docker daemon
=== Docker Daemon
The `build-image` goal requires access to a Docker daemon.
By default, it will communicate with a Docker daemon over a local connection.
This works with https://docs.docker.com/install/[Docker Engine] on all supported platforms without configuration.
@ -58,7 +58,7 @@ On Linux and macOS, these environment variables can be set using the command `ev
[[build-image-customization]]
=== Image customizations
=== Image Customizations
The plugin invokes a {buildpacks-reference}/concepts/components/builder/[builder] to orchestrate the generation of an image.
The builder includes multiple {buildpacks-reference}/concepts/components/buildpack[buildpacks] that can inspect the application to influence the generated image.
If the builder exposes configuration options using environment variables, those can be set using the `env` attributes.
The following example assumes that the default builder defines a `BP_JAVA_VERSION` property (typically used to customize the JDK version the image should use):
@ -197,7 +199,7 @@ When using the default builder, this can be accomplished by setting the `HTTPS_P
[[build-image-example-custom-image-name]]
==== Custom image name
==== Custom Image Name
By default, the image name is inferred from the `artifactId` and the `version` of the project, something like `docker.io/library/${project.artifactId}:${project.version}`.
You can take control over the name, as shown in the following example:
Phillip Webb
5 years ago