Spring/spring-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Use one sentence per line in Actuator and Gradle plugin doc source

Browse Source 
Closes gh-18185
This commit is contained in:
Andy Wilkinson
2019-09-09 10:59:49 +01:00
parent 795c2f225f
commit 7b1e10ed00
30 changed files with 274 additions and 427 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/getting-started.adoc
View File

@@ -4,8 +4,7 @@
To get started with the plugin it needs to be applied to your project.
ifeval::["{version-type}" == "RELEASE"]
The plugin is https://plugins.gradle.org/plugin/org.springframework.boot[published to
Gradle's plugin portal] and can be applied using the `plugins` block:
The plugin is https://plugins.gradle.org/plugin/org.springframework.boot[published to Gradle's plugin portal] and can be applied using the `plugins` block:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
----
@@ -19,18 +18,16 @@ include::../gradle/getting-started/apply-plugin-release.gradle.kts[]
----
endif::[]
ifeval::["{version-type}" == "MILESTONE"]
The plugin is published to the Spring milestones repository. For Gradle versions less
than 4.10, this means that you must apply the plugin imperatively:
The plugin is published to the Spring milestones repository.
For Gradle versions less than 4.10, this means that you must apply the plugin imperatively:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::../gradle/getting-started/apply-plugin-milestone.gradle[]
----
For Gradle 4.10 and above, Gradle can be configured to use the milestones repository
and it can be applied using the `plugins` block. To configure Gradle to use the milestones
repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts`
(Kotlin):
For Gradle 4.10 and above, Gradle can be configured to use the milestones repository and it can be applied using the `plugins` block.
To configure Gradle to use the milestones repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts` (Kotlin):
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -59,18 +56,16 @@ include::../gradle/getting-started/apply-plugin-release.gradle.kts[]
----
endif::[]
ifeval::["{version-type}" == "SNAPSHOT"]
The plugin is published to the Spring snapshots repository. For Gradle versions less
than 4.10, this means that you must apply the plugin imperatively:
The plugin is published to the Spring snapshots repository.
For Gradle versions less than 4.10, this means that you must apply the plugin imperatively:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
include::../gradle/getting-started/apply-plugin-milestone.gradle[]
----
For Gradle 4.10 and above, Gradle can be configured to use the snapshots repository
and it can be applied using the `plugins` block. To configure Gradle to use the snapshots
repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts`
(Kotlin):
For Gradle 4.10 and above, Gradle can be configured to use the snapshots repository and it can be applied using the `plugins` block.
To configure Gradle to use the snapshots repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts` (Kotlin):
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -99,15 +94,11 @@ include::../gradle/getting-started/apply-plugin-release.gradle.kts[]
----
endif::[]
Applied in isolation the plugin makes few changes to a project. Instead, the plugin
detects when certain other plugins are applied and reacts accordingly. For example, when
the `java` plugin is applied a task for building an executable jar is automatically
configured.
A typical Spring Boot project will apply the {groovy-plugin}[`groovy`],
{java-plugin}java_plugin.html[`java`], or {kotlin-plugin}[`org.jetbrains.kotlin.jvm`]
plugin and the {dependency-management-plugin}[`io.spring.dependency-management`] plugin as
a minimum. For example:
Applied in isolation the plugin makes few changes to a project.
Instead, the plugin detects when certain other plugins are applied and reacts accordingly.
For example, when the `java` plugin is applied a task for building an executable jar is automatically configured.
A typical Spring Boot project will apply the {groovy-plugin}[`groovy`], {java-plugin}java_plugin.html[`java`], or {kotlin-plugin}[`org.jetbrains.kotlin.jvm`] plugin and the {dependency-management-plugin}[`io.spring.dependency-management`] plugin as a minimum.
For example:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
@@ -122,5 +113,4 @@ include::../gradle/getting-started/typical-plugins.gradle[tags=apply]
include::../gradle/getting-started/typical-plugins.gradle.kts[tags=apply]
----
To learn more about how the Spring Boot plugin behaves when other plugins are applied
please see the section on <<reacting-to-other-plugins, reacting to other plugins>>.
To learn more about how the Spring Boot plugin behaves when other plugins are applied please see the section on <<reacting-to-other-plugins, reacting to other plugins>>.

9
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/index.adoc
View File

@@ -34,11 +34,10 @@ Andy Wilkinson
[[introduction]]
== Introduction
The Spring Boot Gradle Plugin provides Spring Boot support in https://gradle.org[Gradle],
allowing 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 4.4 or later. If you choose to use the newer Kotlin DSL,
it requires Gradle 4.10 or later.
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 4.4 or later.
If you choose to use the newer Kotlin DSL, it requires Gradle 4.10 or later.
In addition to this user guide, {api-documentation}[API documentation] is also available.

25
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/integrating-with-actuator.adoc
View File

@@ -5,10 +5,9 @@
[[integrating-with-actuator-build-info]]
=== Generating build information
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:
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:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -23,10 +22,8 @@ include::../gradle/integrating-with-actuator/build-info-basic.gradle.kts[tags=bu
----
This will configure a {build-info-javadoc}[`BuildInfo`] task named `bootBuildInfo` and, if
it exists, make the Java plugin's `classes` task depend upon it. The task's destination
directory will be `META-INF` in the output directory of the main source set's resources
(typically `build/resources/main`).
This will configure a {build-info-javadoc}[`BuildInfo`] task named `bootBuildInfo` and, if it exists, make the Java plugin's `classes` task depend upon it.
The task's destination directory will be `META-INF` in the output directory of the main source set's resources (typically `build/resources/main`).
By default, the generated build information is derived from the project:
@@ -66,12 +63,11 @@ include::../gradle/integrating-with-actuator/build-info-custom-values.gradle.kts
----
The default value for `build.time` is the instant at which the project is being built. A
side-effect of this is that the task will never be up-to-date. As a result, builds will
take longer as more tasks, including the project's tests, will have to be executed.
Another side-effect is that the task's output will always change and, therefore, the build
will not be truly repeatable. If you value build performance or repeatability more highly
than the accuracy of the `build.time` property, set `time` to `null` or a fixed value.
The default value for `build.time` is the instant at which the project is being built.
A side-effect of this is that the task will never be up-to-date.
As a result, builds will take longer as more tasks, including the project's tests, will have to be executed.
Another side-effect is that the task's output will always change and, therefore, the build will not be truly repeatable.
If you value build performance or repeatability more highly than the accuracy of the `build.time` property, set `time` to `null` or a fixed value.
Additional properties can also be added to the build information:
@@ -86,4 +82,3 @@ include::../gradle/integrating-with-actuator/build-info-additional.gradle[tags=a
----
include::../gradle/integrating-with-actuator/build-info-additional.gradle.kts[tags=additional]
----

51
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/managing-dependencies.adoc
View File

@@ -1,14 +1,10 @@
[[managing-dependencies]]
== Managing dependencies
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. To make use of this functionality, simply
declare dependencies in the usual way but omit the version number:
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.
To make use of this functionality, simply declare dependencies in the usual way but omit the version number:
[source,groovy,indent=0,subs="verbatim",role="primary"]
.Groovy
@@ -26,13 +22,11 @@ include::../gradle/managing-dependencies/dependencies.gradle.kts[tags=dependenci
[[managing-dependencies-customizing]]
=== Customizing managed versions
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. Please refer to the {github-code}/spring-boot-project/spring-boot-dependencies/pom.xml[bom]
for a complete list of these properties.
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.
Please refer to the {github-code}/spring-boot-project/spring-boot-dependencies/pom.xml[bom] for a complete list of these properties.
To customize a managed version you set its corresponding property. For example, to
customize the version of SLF4J which is controlled by the `slf4j.version` property:
To customize a managed version you set its corresponding property.
For example, to customize the version of SLF4J which is controlled by the `slf4j.version` property:
[source,groovy,indent=0,subs="verbatim",role="primary"]
.Groovy
@@ -47,19 +41,16 @@ include::../gradle/managing-dependencies/custom-version.gradle.kts[tags=custom-v
----
WARNING: Each Spring Boot release is designed and tested against a specific set of
third-party dependencies. Overriding versions may cause compatibility issues and should
be done with care.
WARNING: Each Spring Boot release is designed and tested against a specific set of third-party dependencies.
Overriding versions may cause compatibility issues and should be done with care.
[[managing-dependencies-using-in-isolation]]
=== Using Spring Boot's dependency management in isolation
Spring Boot's dependency management can be used in a project without applying Spring
Boot's plugin to that project. The `SpringBootPlugin` class provides a `BOM_COORDINATES`
constant that can be used to import the bom without having to know its group ID,
artifact ID, or version.
Spring Boot's dependency management can be used in a project without applying Spring Boot's plugin to that project.
The `SpringBootPlugin` class provides a `BOM_COORDINATES` constant that can be used to import the bom without having to know its group ID, artifact ID, or version.
First, configure the project to depend on the Spring Boot plugin but do not apply it:
@@ -101,10 +92,8 @@ include::../gradle/managing-dependencies/depend-on-plugin-release.gradle.kts[]
----
endif::[]
The Spring Boot plugin's dependency on the dependency management plugin means that you
can use the dependency management plugin without having to declare a dependency on it.
This also means that you will automatically use the same version of the dependency
management plugin as Spring Boot uses.
The Spring Boot plugin's dependency on the dependency management plugin means that you can use the dependency management plugin without having to declare a dependency on it.
This also means that you will automatically use the same version of the dependency management plugin as Spring Boot uses.
Apply the dependency management plugin and then configure it to import Spring Boot's bom:
@@ -121,12 +110,11 @@ include::../gradle/managing-dependencies/configure-bom.gradle.kts[tags=configure
----
The Kotlin code above is a bit awkward. That's because we're using the imperative way of
applying the dependency management plugin.
The Kotlin code above is a bit awkward.
That's because we're using the imperative way of applying the dependency management plugin.
We can make the code less awkward by applying the plugin from the root parent project, or
by using the `plugins` block as we're doing for the Spring Boot plugin. A downside of this
method is that it forces us to specify the version of the dependency management plugin:
We can make the code less awkward by applying the plugin from the root parent project, or by using the `plugins` block as we're doing for the Spring Boot plugin.
A downside of this method is that it forces us to specify the version of the dependency management plugin:
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
@@ -137,5 +125,4 @@ include::../gradle/managing-dependencies/configure-bom-with-plugins.gradle.kts[t
[[managing-dependencies-learning-more]]
=== Learning more
To learn more about the capabilities of the dependency management plugin, please refer to
its {dependency-management-plugin-documentation}[documentation].
To learn more about the capabilities of the dependency management plugin, please refer to its {dependency-management-plugin-documentation}[documentation].

100
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/packaging.adoc
View File

@@ -1,37 +1,33 @@
[[packaging-executable]]
== Packaging executable archives
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`.
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
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.
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.
[[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.
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.
[[packaging-executable-wars-deployable]]
==== 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:
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:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -46,21 +42,17 @@ include::../gradle/packaging/war-container-dependency.gradle.kts[tags=dependenci
----
This ensures that they are package in the war file's `WEB-INF/lib-provided` directory
from where they will not conflict with the external container's own classes.
This ensures that they are package in the war file's `WEB-INF/lib-provided` directory from where they will not conflict with the external container's own classes.
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among
other limitations, `compileOnly` dependencies are not on the test classpath so any
web-based integration tests will fail.
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among other limitations, `compileOnly` dependencies are not on the test classpath so any web-based integration tests will fail.
[[packaging-executable-and-normal]]
=== 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:
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:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -75,9 +67,8 @@ include::../gradle/packaging/boot-jar-and-jar.gradle.kts[tags=enable-jar]
----
To avoid the executable archive and the normal archive from being written to the same
location, one or the other should be configured to use a different location. One way to
do so is by configuring a classifier:
To avoid the executable archive and the normal archive from being written to the same location, one or the other should be configured to use a different location.
One way to do so is by configuring a classifier:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -95,22 +86,17 @@ include::../gradle/packaging/boot-jar-and-jar.gradle.kts[tags=classifier]
[[packaging-executable-configuring]]
=== Configuring executable archive packaging
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.
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
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.
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:
The main class can also be configured explicitly using the task's `mainClassName` property:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -125,8 +111,7 @@ include::../gradle/packaging/boot-jar-main-class.gradle.kts[tags=main-class]
----
Alternatively, the main class name can be configured project-wide using the
`mainClassName` property of the Spring Boot DSL:
Alternatively, the main class name can be configured project-wide using the `mainClassName` property of the Spring Boot DSL:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -141,8 +126,7 @@ include::../gradle/packaging/spring-boot-dsl-main-class.gradle.kts[tags=main-cla
----
If the {application-plugin}[`application` plugin] has been applied its `mainClassName`
project property must be configured and can be used for the same purpose:
If the {application-plugin}[`application` plugin] has been applied its `mainClassName` project property must be configured and can be used for the same purpose:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -174,10 +158,8 @@ include::../gradle/packaging/boot-jar-manifest-main-class.gradle.kts[tags=main-c
[[packaging-executable-configuring-excluding-devtools]]
==== Excluding Devtools
By default, Spring Boot's Devtools module,
`org.springframework.boot:spring-boot-devtools`, will be excluded from an executable jar
or war. If you want to include Devtools in your archive set the `excludeDevtools`
property to `false`:
By default, Spring Boot's Devtools module, `org.springframework.boot:spring-boot-devtools`, will be excluded from an executable jar or war.
If you want to include Devtools in your archive set the `excludeDevtools` property to `false`:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -195,14 +177,11 @@ include::../gradle/packaging/boot-war-include-devtools.gradle.kts[tags=include-d
[[packaging-executable-configuring-unpacking]]
==== Configuring libraries that require unpacking
Most libraries can be used directly when nested in an executable archive, however certain
libraries can have problems. For example, JRuby includes its own nested jar support which
assumes that `jruby-complete.jar` is always directly available on the file system.
Most libraries can be used directly when nested in an executable archive, however certain libraries can have problems.
For example, JRuby includes its own nested jar support which assumes that `jruby-complete.jar` is always directly available on the file system.
To deal with any problematic libraries, an executable archive can be configured to unpack
specific nested jars to a temporary folder when the executable archive is run. Libraries
can be identified as requiring unpacking using Ant-style patterns that match against
the absolute path of the source jar file:
To deal with any problematic libraries, an executable archive can be configured to unpack specific nested jars to a temporary folder when the executable archive is run.
Libraries can be identified as requiring unpacking using Ant-style patterns that match against the absolute path of the source jar file:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -217,18 +196,17 @@ include::../gradle/packaging/boot-jar-requires-unpack.gradle.kts[tags=requires-u
----
For more control a closure can also be used. The closure is passed a `FileTreeElement`
and should return a `boolean` indicating whether or not unpacking is required.
For more control a closure can also be used.
The closure is passed a `FileTreeElement` and should return a `boolean` indicating whether or not unpacking is required.
[[packaging-executable-configuring-launch-script]]
==== Making an archive fully executable
Spring Boot provides support for fully executable archives. An archive is made fully
executable by prepending a shell script that knows how to launch the application. On
Unix-like platforms, this launch script allows the archive to be run directly like any
other executable or to be installed as a service.
Spring Boot provides support for fully executable archives.
An archive is made fully executable by prepending a shell script that knows how to launch the application.
On Unix-like platforms, this launch script allows the archive to be run directly like any other executable or to be installed as a service.
To use this feature, the inclusion of the launch script must be enabled:
@@ -245,9 +223,9 @@ include::../gradle/packaging/boot-jar-include-launch-script.gradle.kts[tags=incl
----
This will add Spring Boot's default launch script to the archive. The default launch
script includes several properties with sensible default values. The values can be
customized using the `properties` property:
This will add Spring Boot's default launch script to the archive.
The default launch script includes several properties with sensible default values.
The values can be customized using the `properties` property:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -262,8 +240,7 @@ include::../gradle/packaging/boot-jar-launch-script-properties.gradle.kts[tags=l
----
If the default launch script does not meet your needs, the `script` property can be used
to provide a custom launch script:
If the default launch script does not meet your needs, the `script` property can be used to provide a custom launch script:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -281,8 +258,7 @@ include::../gradle/packaging/boot-jar-custom-launch-script.gradle.kts[tags=custo
[[packaging-executable-configuring-properties-launcher]]
==== Using the `PropertiesLauncher`
To use the `PropertiesLauncher` to launch an executable jar or war, configure the task's
manifest to set the `Main-Class` attribute:
To use the `PropertiesLauncher` to launch an executable jar or war, configure the task's manifest to set the `Main-Class` attribute:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy

25
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/publishing.adoc
View File

@@ -6,11 +6,9 @@
[[publishing-your-application-maven]]
=== Publishing with the `maven` plugin
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 {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:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -28,10 +26,9 @@ include::../gradle/publishing/maven.gradle.kts[tags=upload]
[[publishing-your-application-maven-publish]]
=== Publishing with the `maven-publish` plugin
To publish your Spring Boot jar or war, add it to the publication using the `artifact`
method on `MavenPublication`. Pass the task that produces that artifact that you wish
to publish to the `artifact` method. For example, to publish the artifact produced by the
default `bootJar` task:
To publish your Spring Boot jar or war, add it to the publication using the `artifact` method on `MavenPublication`.
Pass the task that produces that artifact that you wish to publish to the `artifact` method.
For example, to publish the artifact produced by the default `bootJar` task:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -49,9 +46,7 @@ include::../gradle/publishing/maven-publish.gradle.kts[tags=publishing]
[[publishing-your-application-distribution]]
=== Distributing with the `application` plugin
When the {application-plugin}[`application` plugin] is applied a distribution named
`boot` is created. This distribution contains the archive produced by the `bootJar` or
`bootWar` task and scripts to launch it on Unix-like platforms and Windows. Zip and tar
distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively. To
use the `application` plugin, its `mainClassName` project property must be configured
with the name of your application's main class.
When the {application-plugin}[`application` plugin] is applied a distribution named `boot` is created.
This distribution contains the archive produced by the `bootJar` or `bootWar` task and scripts to launch it on Unix-like platforms and Windows.
Zip and tar distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively.
To use the `application` plugin, its `mainClassName` project property must be configured with the name of your application's main class.

68
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/reacting.adoc
View File

@@ -1,27 +1,22 @@
[[reacting-to-other-plugins]]
== Reacting to other plugins
When another plugin is applied the Spring Boot plugin reacts by making various changes
to the project's configuration. This section describes those changes.
When another plugin is applied the Spring Boot plugin reacts by making various changes to the project's configuration.
This section describes those changes.
[[reacting-to-other-plugins-java]]
=== Reacting to the Java plugin
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot
plugin:
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot plugin:
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an
executable, fat jar for the project. The jar will contain everything on the runtime
classpath of the main source set; classes are packaged in `BOOT-INF/classes` and jars
are packaged in `BOOT-INF/lib`
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
The jar will contain everything on the runtime classpath of the main source set; classes are packaged in `BOOT-INF/classes` and jars are packaged in `BOOT-INF/lib`
2. Configures the `assemble` task to depend on the `bootJar` task.
3. Disables the `jar` task.
4. Creates a {boot-run-javadoc}[`BootRun`] task named `bootRun` that can be used to run
your application.
5. Creates a configuration named `bootArchives` that contains the artifact produced by
the `bootJar` task.
4. Creates a {boot-run-javadoc}[`BootRun`] task named `bootRun` that can be used to run your application.
5. Creates a configuration named `bootArchives` that contains the artifact produced by the `bootJar` task.
6. Configures any `JavaCompile` tasks with no configured encoding to use `UTF-8`.
7. Configures any `JavaCompile` tasks to use the `-parameters` compiler argument.
@@ -30,12 +25,10 @@ plugin:
[[reacting-to-other-plugins-kotlin]]
=== Reacting to the Kotlin plugin
When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring Boot
plugin:
When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring Boot plugin:
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version
of the plugin. This is achieved by setting the `kotlin.version` property with a value
that matches the version of the Kotlin plugin.
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version of the plugin.
This is achieved by setting the `kotlin.version` property with a value that matches the version of the Kotlin plugin.
2. Configures any `KotlinCompile` tasks to use the `-java-parameters` compiler argument.
@@ -45,52 +38,37 @@ plugin:
When Gradle's {war-plugin}[`war` plugin] is applied to a project, the Spring Boot plugin:
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an
executable, fat war for the project. In addition to the standard packaging, everything
in the `providedRuntime` configuration will be packaged in `WEB-INF/lib-provided`.
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an executable, fat war for the project.
In addition to the standard packaging, everything in the `providedRuntime` configuration will be packaged in `WEB-INF/lib-provided`.
2. Configures the `assemble` task to depend on the `bootWar` task.
3. Disables the `war` task.
4. Configures the `bootArchives` configuration to contain the artifact produced by the
`bootWar` task.
4. Configures the `bootArchives` configuration to contain the artifact produced by the `bootWar` task.
[[reacting-to-other-plugins-dependency-management]]
=== Reacting to the dependency management plugin
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.
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
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the
Spring Boot 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`. The
task is configured to use the `applicationDefaultJvmArgs` property as a convention
for its `defaultJvmOpts` property.
2. Creates a new distribution named `boot` and configures it to contain the artifact in
the `bootArchives` configuration in its `lib` directory and the start scripts in its
`bin` directory.
3. Configures the `bootRun` task to use the `mainClassName` property as a convention for
its `main` property.
4. Configures the `bootRun` task to use the `applicationDefaultJvmArgs` property as a
convention for its `jvmArgs` property.
5. Configures the `bootJar` task to use the `mainClassName` property as a convention for
the `Start-Class` entry in its manifest.
6. Configures the `bootWar` task to use the `mainClassName` property as a convention for
the `Start-Class` entry in its manifest.
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
The task is configured to use the `applicationDefaultJvmArgs` property as a convention for its `defaultJvmOpts` property.
2. Creates a new distribution named `boot` and configures it to contain the artifact in the `bootArchives` configuration in its `lib` directory and the start scripts in its `bin` directory.
3. Configures the `bootRun` task to use the `mainClassName` property as a convention for its `main` property.
4. Configures the `bootRun` task to use the `applicationDefaultJvmArgs` property as a convention for its `jvmArgs` property.
5. Configures the `bootJar` task to use the `mainClassName` property as a convention for the `Start-Class` entry in its manifest.
6. Configures the `bootWar` task to use the `mainClassName` property as a convention for the `Start-Class` entry in its manifest.
[[reacting-to-other-plugins-maven]]
=== Reacting to the Maven plugin
When Gradle's {maven-plugin}[`maven` plugin] is applied to a project, the Spring Boot
plugin will configure the `uploadBootArchives` `Upload` task to ensure that no
dependencies are declared in the pom that it generates.
When Gradle's {maven-plugin}[`maven` plugin] is applied to a project, the Spring Boot plugin will configure the `uploadBootArchives` `Upload` task to ensure that no dependencies are declared in the pom that it generates.

33
spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/asciidoc/running.adoc
View File

@@ -8,14 +8,11 @@ To run your application without first building an archive use the `bootRun` task
$ ./gradlew bootRun
----
The `bootRun` task is an instance of
{boot-run-javadoc}[`BootRun`] which is a `JavaExec` subclass. As such, all of the
{gradle-dsl}/org.gradle.api.tasks.JavaExec.html[usual configuration options] for executing
a Java process in Gradle are available to you. The task is automatically configured to use
the runtime classpath of the main source set.
The `bootRun` task is an instance of {boot-run-javadoc}[`BootRun`] which is a `JavaExec` subclass.
As such, all of the {gradle-dsl}/org.gradle.api.tasks.JavaExec.html[usual configuration options] for executing a Java process in Gradle are available to you.
The task is automatically configured to use the runtime classpath of the main source set.
By default, the 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.
By default, the 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 `main` property:
@@ -32,8 +29,7 @@ include::../gradle/running/boot-run-main.gradle.kts[tags=main]
----
Alternatively, the main class name can be configured project-wide using the
`mainClassName` property of the Spring Boot DSL:
Alternatively, the main class name can be configured project-wide using the `mainClassName` property of the Spring Boot DSL:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -48,8 +44,7 @@ include::../gradle/running/spring-boot-dsl-main-class-name.gradle.kts[tags=main-
----
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName`
project property must be configured and can be used for the same purpose:
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName` project property must be configured and can be used for the same purpose:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -66,25 +61,22 @@ include::../gradle/running/application-plugin-main-class-name.gradle.kts[tags=ma
[[running-your-application-passing-arguments]]
=== Passing arguments to your application
Like all `JavaExec` tasks, arguments can be passed into `bootRun` from the command line
using `--args='<arguments>'` when using Gradle 4.9 or later. For example, to run your
application with a profile named `dev` active the following command can be used:
Like all `JavaExec` tasks, arguments can be passed into `bootRun` from the command line using `--args='<arguments>'` when using Gradle 4.9 or later.
For example, to run your application with a profile named `dev` active the following command can be used:
[source,bash,indent=0,subs="verbatim"]
----
$ ./gradlew bootRun --args='--spring.profiles.active=dev'
----
See {gradle-api}/org/gradle/api/tasks/JavaExec.html#setArgsString-java.lang.String-[the
javadoc for `JavaExec.setArgsString`] for further details.
See {gradle-api}/org/gradle/api/tasks/JavaExec.html#setArgsString-java.lang.String-[the javadoc for `JavaExec.setArgsString`] for further details.
[[running-your-application-reloading-resources]]
=== Reloading resources
If devtools has been added to your project it will automatically monitor your
application for changes. Alternatively, you can configure `bootRun` such that your
application's static resources are loaded from their source location:
If devtools has been added to your project it will automatically monitor your application for changes.
Alternatively, you can configure `bootRun` such that your application's static resources are loaded from their source location:
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
.Groovy
@@ -99,5 +91,4 @@ include::../gradle/running/boot-run-source-resources.gradle.kts[tags=source-reso
----
This makes them reloadable in the live application which can be helpful at development
time.
This makes them reloadable in the live application which can be helpful at development time.