From 234c5033d4e41f634ec382eced4cffbc4f1a4b43 Mon Sep 17 00:00:00 2001 From: Phillip Webb Date: Thu, 30 Jan 2020 17:02:47 -0800 Subject: [PATCH] Polish whitespace --- .../buildpack/platform/build/Lifecycle.java | 1 - .../docs/asciidoc/packaging-oci-image.adoc | 9 +++++++-- .../src/docs/asciidoc/packaging.adoc | 20 ++++--------------- .../src/docs/asciidoc/publishing.adoc | 5 ++--- .../src/docs/asciidoc/reacting.adoc | 7 ------- .../src/docs/asciidoc/running.adoc | 6 +----- .../src/docs/asciidoc/getting-started.adoc | 1 - .../src/docs/asciidoc/integration-tests.adoc | 2 +- .../docs/asciidoc/packaging-oci-image.adoc | 6 +++++- .../src/docs/asciidoc/packaging.adoc | 4 ++++ .../src/docs/asciidoc/running.adoc | 2 ++ 11 files changed, 26 insertions(+), 37 deletions(-) diff --git a/spring-boot-project/spring-boot-tools/spring-boot-buildpack-platform/src/main/java/org/springframework/boot/buildpack/platform/build/Lifecycle.java b/spring-boot-project/spring-boot-tools/spring-boot-buildpack-platform/src/main/java/org/springframework/boot/buildpack/platform/build/Lifecycle.java index 5588c4f961..6db3d556b0 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-buildpack-platform/src/main/java/org/springframework/boot/buildpack/platform/build/Lifecycle.java +++ b/spring-boot-project/spring-boot-tools/spring-boot-buildpack-platform/src/main/java/org/springframework/boot/buildpack/platform/build/Lifecycle.java @@ -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()); diff --git a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging-oci-image.adoc b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging-oci-image.adoc index 9567dee86d..90b5ad483a 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging-oci-image.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging-oci-image.adoc @@ -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}`. diff --git a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging.adoc b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging.adoc index e3addec755..2eeef841c1 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/packaging.adoc @@ -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: diff --git a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/publishing.adoc b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/publishing.adoc index 467aee1a79..ed1145e8ca 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/publishing.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/publishing.adoc @@ -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. diff --git a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/reacting.adoc b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/reacting.adoc index e8f9920f5b..c00f23c33b 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/reacting.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/reacting.adoc @@ -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. diff --git a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/running.adoc b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/running.adoc index 0154357234..9d449e87e2 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/running.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/asciidoc/running.adoc @@ -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=''` 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. diff --git a/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/getting-started.adoc b/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/getting-started.adoc index e3121cbeac..6a7fb76603 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/getting-started.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/getting-started.adoc @@ -1,6 +1,5 @@ [[getting-started]] == Getting started - The Spring Boot Plugin has the following goals: include::goals/overview.adoc[] diff --git a/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/integration-tests.adoc b/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/integration-tests.adoc index 09e08bce3f..0560781219 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/integration-tests.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/integration-tests.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 diff --git a/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging-oci-image.adoc b/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging-oci-image.adoc index 06d8ae62f7..fd428d8ad2 100644 --- a/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging-oci-image.adoc +++ b/spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging-oci-image.adoc @@ -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 <>, 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 <> and <>. @@ -70,9 +71,12 @@ For more details, see <