mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-08-29 03:06:45 +08:00
Polish whitespace
This commit is contained in:
Phillip Webb
parent
653cabe2ce
commit
234c5033d4
@ -203,7 +203,6 @@ class Lifecycle implements Closeable {
|
||||
try {
|
||||
this.docker.container().start(reference);
|
||||
this.docker.container().logs(reference, logConsumer::accept);
|
||||
|
||||
ContainerStatus status = this.docker.container().wait(reference);
|
||||
if (status.getStatusCode() != 0) {
|
||||
throw new BuilderException(phase.getName(), status.getStatusCode());
|
||||
|
||||
@ -1,10 +1,11 @@
|
||||
[[build-image]]
|
||||
== Packaging OCI images
|
||||
|
||||
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 and a local Docker installation.
|
||||
The task is automatically created when the `java` plugin is applied and is an instance of {boot-build-image-javadoc}[`BootBuildImage`].
|
||||
|
||||
|
||||
|
||||
[[build-image-customization]]
|
||||
=== Image Customizations
|
||||
The plugin invokes a {buildpacks-reference}/concepts/components/builder/[builder] to orchestrate the generation of an image.
|
||||
@ -37,12 +38,15 @@ The following table summarizes the available properties and their default values
|
||||
| `verboseLogging`
|
||||
| Enables verbose logging of builder operations.
|
||||
| `false`
|
||||
|
||||
|===
|
||||
|
||||
|
||||
|
||||
[[build-image-examples]]
|
||||
=== Examples
|
||||
|
||||
|
||||
|
||||
[[build-image-example-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:
|
||||
@ -78,6 +82,7 @@ include::../gradle/packaging/boot-build-image-env.gradle.kts[tags=env]
|
||||
The example above assumes that the builder defines a `BP_JAVA_VERSION` property (typically used to customize the JDK version the image should use).
|
||||
|
||||
|
||||
|
||||
[[build-image-example-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}`.
|
||||
|
||||
@ -1,13 +1,11 @@
|
||||
[[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`.
|
||||
|
||||
|
||||
|
||||
[[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.
|
||||
@ -16,7 +14,6 @@ The `assemble` task is automatically configured to depend upon the `bootJar` tas
|
||||
|
||||
[[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.
|
||||
@ -25,7 +22,6 @@ The `assemble` task is automatically configured to depend upon the `bootWar` tas
|
||||
|
||||
[[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:
|
||||
|
||||
@ -50,7 +46,6 @@ NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as,
|
||||
|
||||
[[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:
|
||||
|
||||
@ -85,7 +80,6 @@ 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.
|
||||
@ -93,7 +87,6 @@ A number of configuration options that are specific to executable jars and wars
|
||||
|
||||
[[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.
|
||||
|
||||
The main class can also be configured explicitly using the task's `mainClassName` property:
|
||||
@ -110,7 +103,6 @@ include::../gradle/packaging/boot-jar-main-class.gradle[tags=main-class]
|
||||
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:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
@ -125,7 +117,6 @@ include::../gradle/packaging/spring-boot-dsl-main-class.gradle[tags=main-class]
|
||||
include::../gradle/packaging/spring-boot-dsl-main-class.gradle.kts[tags=main-class]
|
||||
----
|
||||
|
||||
|
||||
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"]
|
||||
@ -155,9 +146,9 @@ 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`:
|
||||
|
||||
@ -174,9 +165,9 @@ 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.
|
||||
|
||||
@ -203,7 +194,6 @@ The closure is passed a `FileTreeElement` and should return a `boolean` indicati
|
||||
|
||||
[[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.
|
||||
@ -222,7 +212,6 @@ include::../gradle/packaging/boot-jar-include-launch-script.gradle[tags=include-
|
||||
include::../gradle/packaging/boot-jar-include-launch-script.gradle.kts[tags=include-launch-script]
|
||||
----
|
||||
|
||||
|
||||
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:
|
||||
@ -239,7 +228,6 @@ include::../gradle/packaging/boot-jar-launch-script-properties.gradle[tags=launc
|
||||
include::../gradle/packaging/boot-jar-launch-script-properties.gradle.kts[tags=launch-script-properties]
|
||||
----
|
||||
|
||||
|
||||
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"]
|
||||
@ -255,9 +243,9 @@ 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:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
@ -273,9 +261,9 @@ include::../gradle/packaging/boot-war-properties-launcher.gradle.kts[tags=proper
|
||||
----
|
||||
|
||||
|
||||
|
||||
[[packaging-layered-jars]]
|
||||
==== Packaging layered jars
|
||||
|
||||
By default, the `bootJar` tasks 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, the jar format can be enhanced to support layer folders.
|
||||
To use this feature, the layering feature must be enabled:
|
||||
|
||||
@ -5,7 +5,6 @@
|
||||
|
||||
[[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:
|
||||
@ -23,9 +22,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:
|
||||
@ -43,9 +42,9 @@ 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.
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
[[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.
|
||||
|
||||
@ -8,7 +7,6 @@ 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:
|
||||
|
||||
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
|
||||
@ -25,7 +23,6 @@ When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring B
|
||||
|
||||
[[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:
|
||||
|
||||
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version of the plugin.
|
||||
@ -36,7 +33,6 @@ When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring
|
||||
|
||||
[[reacting-to-other-plugins-war]]
|
||||
=== Reacting to the war 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.
|
||||
@ -49,14 +45,12 @@ When Gradle's {war-plugin}[`war` plugin] is applied to a project, the Spring Boo
|
||||
|
||||
[[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.
|
||||
|
||||
|
||||
|
||||
[[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:
|
||||
|
||||
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
|
||||
@ -71,5 +65,4 @@ When Gradle's {application-plugin}[`application` plugin] is applied to a project
|
||||
|
||||
[[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.
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
[[running-your-application]]
|
||||
== Running your application with Gradle
|
||||
|
||||
To run your application without first building an archive use the `bootRun` task:
|
||||
|
||||
[source,bash,indent=0,subs="verbatim"]
|
||||
@ -28,7 +27,6 @@ include::../gradle/running/boot-run-main.gradle[tags=main]
|
||||
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:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
@ -43,7 +41,6 @@ include::../gradle/running/spring-boot-dsl-main-class-name.gradle[tags=main-clas
|
||||
include::../gradle/running/spring-boot-dsl-main-class-name.gradle.kts[tags=main-class]
|
||||
----
|
||||
|
||||
|
||||
By default, `bootRun` will configure the JVM to optimize its launch for faster startup during development.
|
||||
This behavior can be disabled by using the `optimizedLaunch` property, as shown in the following example:
|
||||
|
||||
@ -59,7 +56,6 @@ include::../gradle/running/boot-run-disable-optimized-launch.gradle[tags=launch]
|
||||
include::../gradle/running/boot-run-disable-optimized-launch.gradle.kts[tags=launch]
|
||||
----
|
||||
|
||||
|
||||
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName` property must be configured and can be used for the same purpose:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
@ -75,6 +71,7 @@ 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.
|
||||
@ -106,5 +103,4 @@ include::../gradle/running/boot-run-source-resources.gradle[tags=source-resource
|
||||
include::../gradle/running/boot-run-source-resources.gradle.kts[tags=source-resources]
|
||||
----
|
||||
|
||||
|
||||
This makes them reloadable in the live application which can be helpful at development time.
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
[[getting-started]]
|
||||
== Getting started
|
||||
|
||||
The Spring Boot Plugin has the following goals:
|
||||
|
||||
include::goals/overview.adoc[]
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
[[integration-tests]]
|
||||
== Running Integration tests
|
||||
|
||||
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:
|
||||
|
||||
@ -40,6 +39,7 @@ include::goals/start.adoc[leveloffset=+1]
|
||||
include::goals/stop.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
|
||||
[[integration-tests-example]]
|
||||
=== Examples
|
||||
|
||||
|
||||
@ -30,6 +30,8 @@ It is possible to automate the creation of an image whenever the `package` phase
|
||||
TIP: While the buildpack runs from an <<repackage,executable archive>>, it is not necessary to execute the `repackage` goal first as the executable archive is created automatically if necessary.
|
||||
When the `build-image` repackages the application, it applies the same settings as the `repackage` goal would, i.e. dependencies can be excluded using one of the exclude options, and Devtools is automatically excluded by default (you can control that using the `excludeDevtools` property).
|
||||
|
||||
|
||||
|
||||
[[build-image-customization]]
|
||||
=== Image Customizations
|
||||
The plugin invokes a {buildpacks-reference}/concepts/components/builder/[builder] to orchestrate the generation of an image.
|
||||
@ -62,7 +64,6 @@ The following table summarizes the available properties and their default values
|
||||
| `verboseLogging`
|
||||
| Enables verbose logging of builder operations.
|
||||
| `false`
|
||||
|
||||
|===
|
||||
|
||||
For more details, see <<build-image-example-custom-image-builder,custom image builder>> and <<build-image-example-custom-image-name,custom image name>>.
|
||||
@ -70,9 +71,12 @@ For more details, see <<build-image-example-custom-image-builder,custom image bu
|
||||
include::goals/build-image.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
|
||||
[[build-image-examples]]
|
||||
=== Examples
|
||||
|
||||
|
||||
|
||||
[[build-image-example-custom-image-builder]]
|
||||
==== Custom Image Builder
|
||||
If you need to customize the builder used to create the image, configure yours as shown in the following example:
|
||||
|
||||
@ -73,9 +73,13 @@ The `layout` property defaults to a guess based on the archive type (`jar` or `w
|
||||
|
||||
include::goals/repackage.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
|
||||
[[repackage-examples]]
|
||||
=== Examples
|
||||
|
||||
|
||||
|
||||
[[repackage-example-custom-classifier]]
|
||||
==== Custom Classifier
|
||||
By default, the `repackage` goal replaces the original artifact with the repackaged one.
|
||||
|
||||
@ -80,6 +80,8 @@ Note that this is only applied when you run an application: the `repackage` goal
|
||||
|
||||
include::goals/run.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
|
||||
[[run-examples]]
|
||||
=== Examples
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user