Polish whitespace

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());

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}`.

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:

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.

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.

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='<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.

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[]

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
 

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 <<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:

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging.adoc

@@ -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.

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/running.adoc

@@ -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