Migrate maven-plugin to Antora

See gh-33766

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/build.gradle

@@ -1,5 +1,5 @@
 plugins {
-	id "org.asciidoctor.jvm.convert"
+	id "org.antora"
 	id "org.springframework.boot.conventions"
 	id "org.springframework.boot.maven-plugin"
 	id "org.springframework.boot.optional-dependencies"
@@ -9,12 +9,10 @@ description = "Spring Boot Maven Plugin"
 
 configurations {
 	dependenciesBom
-	documentation
+	antoraContent
 }
 
 dependencies {
-	asciidoctorExtensions("io.spring.asciidoctor:spring-asciidoctor-extensions-section-ids")
-
 	compileOnly("org.apache.maven.plugin-tools:maven-plugin-annotations")
 	compileOnly("org.sonatype.plexus:plexus-build-api")
 	compileOnly("org.apache.maven:maven-core") {
@@ -37,6 +35,21 @@ dependencies {
 	implementation("org.springframework:spring-core")
 	implementation("org.springframework:spring-context")
 
+	testImplementation("org.apache.maven:maven-core") {
+		exclude(group: "javax.annotation", module: "javax.annotation-api")
+		exclude(group: "javax.inject", module: "javax.inject")
+	}
+	testImplementation("org.apache.maven.shared:maven-common-artifact-filters") {
+		exclude(group: "javax.annotation", module: "javax.annotation-api")
+		exclude(group: "javax.enterprise", module: "cdi-api")
+		exclude(group: "javax.inject", module: "javax.inject")
+	}
+	testImplementation("org.assertj:assertj-core")
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testImplementation("org.mockito:mockito-core")
+	testImplementation("org.mockito:mockito-junit-jupiter")
+	testImplementation("org.springframework:spring-core")
+
 	intTestImplementation(project(":spring-boot-project:spring-boot-tools:spring-boot-buildpack-platform"))
 	intTestImplementation(project(":spring-boot-project:spring-boot-tools:spring-boot-loader-tools"))
 	intTestImplementation(project(":spring-boot-project:spring-boot-tools:spring-boot-test-support"))
@@ -61,21 +74,6 @@ dependencies {
 
 	runtimeOnly("org.sonatype.plexus:plexus-build-api")
 
-	testImplementation("org.apache.maven:maven-core") {
-		exclude(group: "javax.annotation", module: "javax.annotation-api")
-		exclude(group: "javax.inject", module: "javax.inject")
-	}
-	testImplementation("org.apache.maven.shared:maven-common-artifact-filters") {
-		exclude(group: "javax.annotation", module: "javax.annotation-api")
-		exclude(group: "javax.enterprise", module: "cdi-api")
-		exclude(group: "javax.inject", module: "javax.inject")
-	}
-	testImplementation("org.assertj:assertj-core")
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testImplementation("org.mockito:mockito-core")
-	testImplementation("org.mockito:mockito-junit-jupiter")
-	testImplementation("org.springframework:spring-core")
-
 	versionProperties(project(path: ":spring-boot-project:spring-boot-dependencies", configuration: "effectiveBom"))
 }
 
@@ -84,12 +82,6 @@ ext {
 	xsdVersion = versionElements[0] + "." + versionElements[1]
 }
 
-syncDocumentationSourceForAsciidoctor {
-	from(documentPluginGoals) {
-		into "asciidoc/goals"
-	}
-}
-
 sourceSets {
 	main {
 		output.dir("${buildDir}/generated/resources/xsd", builtBy: "xsdResources")
@@ -99,30 +91,6 @@ sourceSets {
 	}
 }
 
-tasks.withType(org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask) {
-	doFirst {
-		attributes "spring-boot-xsd-version" : project.ext.xsdVersion
-	}
-}
-
-asciidoctor {
-	sources {
-		include "index.adoc"
-	}
-}
-
-task asciidoctorPdf(type: org.asciidoctor.gradle.jvm.AsciidoctorTask) {
-	sources {
-		include "index.adoc"
-	}
-}
-
-syncDocumentationSourceForAsciidoctorPdf {
-	from(documentPluginGoals) {
-		into "asciidoc/goals"
-	}
-}
-
 javadoc {
 	options {
 		author = true
@@ -136,21 +104,6 @@ javadoc {
 	}
 }
 
-task zip(type: Zip) {
-	dependsOn asciidoctor, asciidoctorPdf
-	duplicatesStrategy "fail"
-	from(asciidoctorPdf.outputDir) {
-		into "reference/pdf"
-		rename "index.pdf", "${project.name}-reference.pdf"
-	}
-	from(asciidoctor.outputDir) {
-		into "reference/htmlsingle"
-	}
-	from(javadoc) {
-		into "api"
-	}
-}
-
 task xsdResources(type: Sync) {
 	from "src/main/xsd/layers-${project.ext.xsdVersion}.xsd"
 	into "${buildDir}/generated/resources/xsd/org/springframework/boot/maven"
@@ -161,10 +114,6 @@ prepareMavenBinaries {
 	versions "3.9.0", "3.8.5", "3.6.3"
 }
 
-artifacts {
-	"documentation" zip
-}
-
 tasks.named("documentPluginGoals") {
 	goalSections = [
 		"build-image": "build-image",
@@ -180,3 +129,43 @@ tasks.named("documentPluginGoals") {
 		"test-run": "run"
 	]
 }
+
+def antoraMavenPluginLocalAggregateContent  = tasks.register("antoraMavenPluginLocalAggregateContent", Zip) {
+	destinationDirectory = layout.buildDirectory.dir('generated/docs/antora-content')
+	archiveClassifier = "maven-plugin-local-aggregate-content"
+	from(tasks.getByName("generateAntoraYml")) {
+		into "modules"
+	}
+}
+
+def antoraMavenPluginAggregateContent = tasks.register("antoraMavenPluginAggregateContent", Zip) {
+	destinationDirectory = layout.buildDirectory.dir('generated/docs/antora-content')
+	archiveClassifier = "maven-plugin-aggregate-content"
+	from(documentPluginGoals) {
+		into "modules/maven-plugin/partials/goals"
+	}
+}
+
+def antoraMavenPluginCatalogContent = tasks.register("antoraMavenPluginCatalogContent", Zip) {
+	destinationDirectory = layout.buildDirectory.dir('generated/docs/antora-content')
+	archiveClassifier = "maven-plugin-catalog-content"
+	from(javadoc) {
+		into "api/java"
+	}
+}
+
+tasks.named("generateAntoraPlaybook") {
+	xrefStubs = ["appendix:.*", "api:.*", "reference:.*"]
+	alwaysInclude = [name: "maven-plugin", classifier: "local-aggregate-content"]
+	dependsOn antoraMavenPluginLocalAggregateContent
+}
+
+
+tasks.named("antora") {
+	inputs.files(antoraMavenPluginLocalAggregateContent, antoraMavenPluginAggregateContent, antoraMavenPluginCatalogContent)
+}
+
+artifacts {
+	antoraContent antoraMavenPluginAggregateContent
+	antoraContent antoraMavenPluginCatalogContent
+}

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/antora.yml

@@ -0,0 +1,10 @@
+name: spring-boot
+ext:
+  zip_contents_collector:
+    include:
+    - name: maven-plugin
+      classifier: aggregate-content
+    - name: maven-plugin
+      classifier: catalog-content
+      module: maven-plugin
+      destination: content-catalog

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/local-nav.adoc

@@ -0,0 +1 @@
+include::maven-plugin:partial$nav-maven-plugin.adoc[]

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/examples/packaging/layers-configuration.xml

@@ -2,7 +2,7 @@
 <layers xmlns="http://www.springframework.org/schema/boot/layers"
 		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 		xsi:schemaLocation="http://www.springframework.org/schema/boot/layers
-						  https://www.springframework.org/schema/boot/layers/layers-{spring-boot-xsd-version}.xsd">
+						  {url-spring-boot-layers-xsd}">
 	<application>
 		<into layer="spring-boot-loader">
 			<include>org/springframework/boot/loader/**</include>

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/examples/packaging/layers.xml

@@ -2,7 +2,7 @@
 <layers xmlns="http://www.springframework.org/schema/boot/layers"
 		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 		xsi:schemaLocation="http://www.springframework.org/schema/boot/layers
-	                      https://www.springframework.org/schema/boot/layers/layers-{spring-boot-xsd-version}.xsd">
+	                      {url-spring-boot-layers-xsd}">
 	<application>
 		<into layer="spring-boot-loader">
 			<include>org/springframework/boot/loader/**</include>

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/examples/using/no-starter-parent-override-dependencies-pom.xml

@@ -32,7 +32,7 @@
 			<dependency>
 				<groupId>org.springframework.boot</groupId>
 				<artifactId>spring-boot-dependencies</artifactId>
-				<version>{gradle-project-version}</version>
+				<version>{version-spring-boot}</version>
 				<type>pom</type>
 				<scope>import</scope>
 			</dependency>

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/examples/using/no-starter-parent-pom.xml

@@ -19,7 +19,7 @@
 				<!-- Import dependency management from Spring Boot -->
 				<groupId>org.springframework.boot</groupId>
 				<artifactId>spring-boot-dependencies</artifactId>
-				<version>{gradle-project-version}</version>
+				<version>{version-spring-boot}</version>
 				<type>pom</type>
 				<scope>import</scope>
 			</dependency>

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/aot.adoc

@@ -4,93 +4,97 @@
 Spring AOT is a process that analyzes your application at build-time and generate an optimized version of it.
 It is a mandatory step to run a Spring `ApplicationContext` in a native image.
 
-NOTE: For an overview of GraalVM Native Images support in Spring Boot, check the {spring-boot-reference}/#native-image[reference documentation].
+NOTE: For an overview of GraalVM Native Images support in Spring Boot, check the xref:reference:native-image/index.adoc[reference documentation].
 
 The Spring Boot Maven plugin offers goals that can be used to perform AOT processing on both application and test code.
 
 
+
 [[aot.processing-applications]]
 == Processing Applications
+
 To configure your application to use this feature, add an execution for the `process-aot` goal, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/aot/pom.xml[tags=aot]
+include::example$aot/pom.xml[tags=aot]
 ----
 
 As the `BeanFactory` is fully prepared at build-time, conditions are also evaluated.
 This has an important difference compared to what a regular Spring Boot application does at runtime.
 For instance, if you want to opt-in or opt-out for certain features, you need to configure the environment used at build time to do so.
-The `process-aot` goal shares a number of properties with the <<run,run goal>> for that reason.
+The `process-aot` goal shares a number of properties with the xref:run.adoc[run goal] for that reason.
+
 
 
 [[aot.processing-applications.using-the-native-profile]]
 === Using the Native Profile
+
 If you use `spring-boot-starter-parent` as the `parent` of your project, a `native` profile can be used to streamline the steps required to build a native image.
 
 The `native` profile configures the following:
 
 * Execution of `process-aot` when the Spring Boot Maven Plugin is applied on a project.
-* Suitable settings so that <<build-image,build-image>> generates a native image.
-* Sensible defaults for the {nbt-reference}[Native Build Tools Maven Plugin], in particular:
+* Suitable settings so that xref:build-image.adoc[build-image] generates a native image.
+* Sensible defaults for the {url-native-build-tools-docs-maven-plugin}[Native Build Tools Maven Plugin], in particular:
 ** Making sure the plugin uses the raw classpath, and not the main jar file as it does not understand our repackaged jar format.
 ** Validate that a suitable GraalVM version is available.
 ** Download third-party reachability metadata.
 
 To benefit from the `native` profile, a module that represents an application should define two plugins, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/aot-native/pom.xml[tags=aot-native]
+include::example$aot-native/pom.xml[tags=aot-native]
 ----
 
-A single project can trigger the generation of a native image on the command-line using either {spring-boot-reference}/#native-image.developing-your-first-application.buildpacks.maven[Cloud Native Buildpacks] or {spring-boot-reference}/#native-image.developing-your-first-application.native-build-tools.maven[Native Image Build Tools].
+A single project can trigger the generation of a native image on the command-line using either xref:reference:native-image/developing-your-first-application.adoc#native-image.developing-your-first-application.buildpacks.maven[Cloud Native Buildpacks] or xref:reference:native-image/developing-your-first-application.adoc#native-image.developing-your-first-application.native-build-tools.maven[Native Image Build Tools].
 
 To use the `native` profile with a multi-modules project, you can create a customization of the `native` profile so that it invokes your preferred technique.
 
 To bind Cloud Native Buildpacks during the `package` phase, add the following to the root POM of your multi-modules project:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/aot-native-profile-buildpacks/pom.xml[tags=profile]
+include::example$aot-native-profile-buildpacks/pom.xml[tags=profile]
 ----
 
 The example below does the same for Native Build Tools:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/aot-native-profile-nbt/pom.xml[tags=profile]
+include::example$aot-native-profile-nbt/pom.xml[tags=profile]
 ----
 
 Once the above is in place, you can build your multi-modules project and generate a native image in the relevant sub-modules, as shown in the following example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn package -Pnative
+$ mvn package -Pnative
 ----
 
 NOTE: A "relevant" sub-module is a module that represents a Spring Boot application.
 Such module must define the Native Build Tools and Spring Boot plugins as described above.
 
+include::partial$goals/process-aot.adoc[leveloffset=+1]
 
 
-include::goals/process-aot.adoc[leveloffset=+1]
-
 
 [[aot.processint-tests]]
 == Processing Tests
+
 The AOT engine can be applied to JUnit 5 tests that use Spring's Test Context Framework.
-Suitable tests are processed by the AOT engine in order to generate `ApplicationContextInitialzer` code.
+Suitable tests are processed by the AOT engine in order to generate `ApplicationContextInitializer` code.
 
 To configure your application to use this feature, add an execution for the `process-test-aot` goal, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/aot-test/pom.xml[tags=aot]
+include::example$aot-test/pom.xml[tags=aot]
 ----
 
 TIP: If you are using `spring-boot-starter-parent`, this execution is automatically configured if you enable the `nativeTest` profile.
 
 As with application AOT processing, the `BeanFactory` is fully prepared at build-time.
 
-include::goals/process-test-aot.adoc[leveloffset=+1]
+include::partial$goals/process-test-aot.adoc[leveloffset=+1]

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/build-image.adoc

@@ -1,25 +1,26 @@
 [[build-image]]
 = Packaging OCI Images
+
 The plugin can create an https://github.com/opencontainers/image-spec[OCI image] from a jar or war file using https://buildpacks.io/[Cloud Native Buildpacks] (CNB).
 Images can be built on the command-line using the `build-image` goal.
 This makes sure that the package lifecycle has run before the image is created.
 
 NOTE: For security reasons, images build and run as non-root users.
-See the {buildpacks-reference}/reference/spec/platform-api/#users[CNB specification] for more details.
+See the {url-buildpacks-docs}/reference/spec/platform-api/#users[CNB specification] for more details.
 
 The easiest way to get started is to invoke `mvn spring-boot:build-image` on a project.
 It is possible to automate the creation of an image whenever the `package` phase is invoked, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/pom.xml[tags=packaging-oci-image]
+include::example$packaging-oci-image/pom.xml[tags=packaging-oci-image]
 ----
 
 NOTE: Use `build-image-no-fork` when binding the goal to the package lifecycle.
 This goal is similar to `build-image` but does not fork the lifecycle to make sure `package` has run.
 In the rest of this section, `build-image` is used to refer to either the `build-image` or `build-image-no-fork` goals.
 
-TIP: While the buildpack runs from an <<packaging,executable archive>>, it is not necessary to execute the `repackage` goal first as the executable archive is created automatically if necessary.
+TIP: While the buildpack runs from an xref:packaging.adoc[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, that is dependencies can be excluded using one of the exclude options.
 The `spring-boot-devtools` and `spring-boot-docker-compose` modules are automatically excluded by default (you can control this using the `excludeDevtools` and `excludeDockerCompose` properties).
 
@@ -27,6 +28,7 @@ The `spring-boot-devtools` and `spring-boot-docker-compose` modules are automati
 
 [[build-image.docker-daemon]]
 == Docker Daemon
+
 The `build-image` goal requires access to a Docker daemon.
 The goal will inspect local Docker CLI https://docs.docker.com/engine/reference/commandline/cli/#configuration-files[configuration files] to determine the current https://docs.docker.com/engine/context/working-with-contexts/[context] and use the context connection information to communicate with a Docker daemon.
 If the current context can not be determined or the context does not have connection information, then the goal will use a default local connection.
@@ -76,12 +78,13 @@ The following table summarizes the available parameters:
 | When `true`, the value of the `host` property will be provided to the container that is created for the CNB builder (optional)
 |===
 
-For more details, see also <<build-image.examples.docker,examples>>.
+For more details, see also xref:build-image.adoc#build-image.examples.docker[examples].
 
 
 
 [[build-image.docker-registry]]
 == Docker Registry
+
 If the Docker images specified by the `builder` or `runImage` parameters are stored in a private Docker image registry that requires authentication, the authentication credentials can be provided using `docker.builderRegistry` parameters.
 
 If the generated Docker image is to be published to a Docker image registry, the authentication credentials can be provided using `docker.publishRegistry` parameters.
@@ -110,14 +113,15 @@ The following table summarizes the available parameters for `docker.builderRegis
 | Identity token for the Docker image registry user. Required for token authentication.
 |===
 
-For more details, see also <<build-image.examples.docker,examples>>.
+For more details, see also xref:build-image.adoc#build-image.examples.docker[examples].
 
 
 
 [[build-image.customization]]
 == Image Customizations
-The plugin invokes a {buildpacks-reference}/concepts/components/builder/[builder] to orchestrate the generation of an image.
-The builder includes multiple {buildpacks-reference}/concepts/components/buildpack[buildpacks] that can inspect the application to influence the generated image.
+
+The plugin invokes a {url-buildpacks-docs}/concepts/components/builder/[builder] to orchestrate the generation of an image.
+The builder includes multiple {url-buildpacks-docs}/concepts/components/buildpack[buildpacks] that can inspect the application to influence the generated image.
 By default, the plugin chooses a builder image.
 The name of the generated image is deduced from project properties.
 
@@ -140,13 +144,13 @@ The following table summarizes the available parameters and their default values
 
 | `name` +
 (`spring-boot.build-image.imageName`)
-| {spring-boot-api}/buildpack/platform/docker/type/ImageReference.html#of-java.lang.String-[Image name] for the generated image.
+| xref:api:java/org/springframework/boot/buildpack/platform/docker/type/ImageReference.html#of-java.lang.String-[Image name] for the generated image.
 | `docker.io/library/` +
 `${project.artifactId}:${project.version}`
 
 | `pullPolicy` +
 (`spring-boot.build-image.pullPolicy`)
-| {spring-boot-api}/buildpack/platform/build/PullPolicy.html[Policy] used to determine when to pull the builder and run images from the registry.
+| xref:api:java/org/springframework/boot/buildpack/platform/build/PullPolicy.html[Policy] used to determine when to pull the builder and run images from the registry.
 Acceptable values are `ALWAYS`, `NEVER`, and `IF_NOT_PRESENT`.
 | `ALWAYS`
 
@@ -200,7 +204,7 @@ The value supplied will be passed unvalidated to Docker when creating the builde
 | `tags`
 | One or more additional tags to apply to the generated image.
 The values provided to the `tags` option should be *full* image references.
-See <<build-image.customization.tags, the tags section>> for more details.
+See xref:build-image.adoc#build-image.customization.tags[the tags section] for more details.
 |
 
 | `buildWorkspace`
@@ -239,9 +243,9 @@ Application contents will also be in this location in the generated image.
 
 NOTE: The plugin detects the target Java compatibility of the project using the compiler's plugin configuration or the `maven.compiler.target` property.
 When using the default Paketo builder and buildpacks, the plugin instructs the buildpacks to install the same Java version.
-You can override this behaviour as shown in the <<build-image.examples.builder-configuration,builder configuration>> examples.
+You can override this behaviour as shown in the xref:build-image.adoc#build-image.examples.builder-configuration[builder configuration] examples.
 
-For more details, see also <<build-image.examples,examples>>.
+For more details, see also xref:build-image.adoc#build-image.examples[examples].
 
 
 
@@ -261,8 +265,8 @@ Some examples:
 * `my-repository/my-image` leads to `docker.io/my-repository/my-image:latest`
 * `example.com/my-repository/my-image:1.0.0` will be used as is
 
-include::goals/build-image.adoc[leveloffset=+1]
-include::goals/build-image-no-fork.adoc[leveloffset=+1]
+include::partial$goals/build-image.adoc[leveloffset=+1]
+include::partial$goals/build-image-no-fork.adoc[leveloffset=+1]
 
 
 
@@ -273,67 +277,71 @@ include::goals/build-image-no-fork.adoc[leveloffset=+1]
 
 [[build-image.examples.custom-image-builder]]
 === Custom Image Builder
+
 If you need to customize the builder used to create the image or the run image used to launch the built image, configure the plugin as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/custom-image-builder-pom.xml[tags=custom-image-builder]
+include::example$packaging-oci-image/custom-image-builder-pom.xml[tags=custom-image-builder]
 ----
 
 This configuration will use a builder image with the name `mine/java-cnb-builder` and the tag `latest`, and the run image named `mine/java-cnb-run` and the tag `latest`.
 
 The builder and run image can be specified on the command line as well, as shown in this example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:build-image -Dspring-boot.build-image.builder=mine/java-cnb-builder -Dspring-boot.build-image.runImage=mine/java-cnb-run
+$ mvn spring-boot:build-image -Dspring-boot.build-image.builder=mine/java-cnb-builder -Dspring-boot.build-image.runImage=mine/java-cnb-run
 ----
 
 
 
 [[build-image.examples.builder-configuration]]
 === Builder Configuration
+
 If the builder exposes configuration options using environment variables, those can be set using the `env` attributes.
 
-The following is an example of {paketo-java-reference}/#configuring-the-jvm-version[configuring the JVM version] used by the Paketo Java buildpacks at build time:
+The following is an example of {url-paketo-docs-java-buildpack}/#configuring-the-jvm-version[configuring the JVM version] used by the Paketo Java buildpacks at build time:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/build-image-example-builder-configuration-pom.xml[tags=build-image-example-builder-configuration]
+include::example$packaging-oci-image/build-image-example-builder-configuration-pom.xml[tags=build-image-example-builder-configuration]
 ----
 
 If there is a network proxy between the Docker daemon the builder runs in and network locations that buildpacks download artifacts from, you will need to configure the builder to use the proxy.
 When using the Paketo builder, this can be accomplished by setting the `HTTPS_PROXY` and/or `HTTP_PROXY` environment variables as show in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/paketo-pom.xml[tags=paketo]
+include::example$packaging-oci-image/paketo-pom.xml[tags=paketo]
 ----
 
 
 
 [[build-image.examples.runtime-jvm-configuration]]
 === Runtime JVM Configuration
-Paketo Java buildpacks {paketo-java-reference}/#runtime-jvm-configuration[configure the JVM runtime environment] by setting the `JAVA_TOOL_OPTIONS` environment variable.
+
+Paketo Java buildpacks {url-paketo-docs-java-buildpack}/#runtime-jvm-configuration[configure the JVM runtime environment] by setting the `JAVA_TOOL_OPTIONS` environment variable.
 The buildpack-provided `JAVA_TOOL_OPTIONS` value can be modified to customize JVM runtime behavior when the application image is launched in a container.
 
-Environment variable modifications that should be stored in the image and applied to every deployment can be set as described in the {paketo-reference}/buildpacks/configuration/#environment-variables[Paketo documentation] and shown in the following example:
+Environment variable modifications that should be stored in the image and applied to every deployment can be set as described in the {url-paketo-docs}/buildpacks/configuration/#environment-variables[Paketo documentation] and shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/runtime-jvm-configuration-pom.xml[tags=runtime-jvm-configuration]
+include::example$packaging-oci-image/runtime-jvm-configuration-pom.xml[tags=runtime-jvm-configuration]
 ----
 
 
 
 [[build-image.examples.custom-image-name]]
 === Custom Image Name
+
 By default, the image name is inferred from the `artifactId` and the `version` of the project, something like `docker.io/library/${project.artifactId}:${project.version}`.
 You can take control over the name, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/custom-image-name-pom.xml[tags=custom-image-name]
+include::example$packaging-oci-image/custom-image-name-pom.xml[tags=custom-image-name]
 ----
 
 NOTE: This configuration does not provide an explicit tag so `latest` is used.
@@ -341,24 +349,25 @@ It is possible to specify a tag as well, either using `${project.version}`, any
 
 The image name can be specified on the command line as well, as shown in this example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:build-image -Dspring-boot.build-image.imageName=example.com/library/my-app:v1
+$ mvn spring-boot:build-image -Dspring-boot.build-image.imageName=example.com/library/my-app:v1
 ----
 
 
 
 [[build-image.examples.buildpacks]]
 === Buildpacks
+
 By default, the builder will use buildpacks included in the builder image and apply them in a pre-defined order.
 An alternative set of buildpacks can be provided to apply buildpacks that are not included in the builder, or to change the order of included buildpacks.
 When one or more buildpacks are provided, only the specified buildpacks will be applied.
 
 The following example instructs the builder to use a custom buildpack packaged in a `.tgz` file, followed by a buildpack included in the builder.
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/buildpacks-pom.xml[tags=buildpacks]
+include::example$packaging-oci-image/buildpacks-pom.xml[tags=buildpacks]
 ----
 
 Buildpacks can be specified in any of the forms shown below.
@@ -393,6 +402,7 @@ An OCI image containing a https://buildpacks.io/docs/buildpack-author-guide/pack
 
 [[build-image.examples.publish]]
 === Image Publishing
+
 The generated image can be published to a Docker registry by enabling a `publish` option.
 
 If the Docker registry requires authentication, the credentials can be configured using `docker.publishRegistry` parameters.
@@ -401,50 +411,51 @@ If the Docker registry does not require authentication, the `docker.publishRegis
 NOTE: The registry that the image will be published to is determined by the registry part of the image name (`docker.example.com` in these examples).
 If `docker.publishRegistry` credentials are configured and include a `url` parameter, this value is passed to the registry but is not used to determine the publishing registry location.
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-pom.xml[tags=docker]
+include::example$packaging-oci-image/docker-pom.xml[tags=docker]
 ----
 
 The `publish` option can be specified on the command line as well, as shown in this example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:build-image -Dspring-boot.build-image.imageName=docker.example.com/library/my-app:v1 -Dspring-boot.build-image.publish=true
+$ mvn spring-boot:build-image -Dspring-boot.build-image.imageName=docker.example.com/library/my-app:v1 -Dspring-boot.build-image.publish=true
 ----
 
 When using the `publish` option on the command line with authentication, you can provide credentials using properties as in this example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:build-image \
-          -Ddocker.publishRegistry.username=user \
-          -Ddocker.publishRegistry.password=secret \
-          -Ddocker.publishRegistry.url=docker.example.com \
-          -Dspring-boot.build-image.publish=true \
-          -Dspring-boot.build-image.imageName=docker.example.com/library/my-app:v1
+$ mvn spring-boot:build-image \
+      -Ddocker.publishRegistry.username=user \
+      -Ddocker.publishRegistry.password=secret \
+      -Ddocker.publishRegistry.url=docker.example.com \
+      -Dspring-boot.build-image.publish=true \
+      -Dspring-boot.build-image.imageName=docker.example.com/library/my-app:v1
 ----
 
 and reference the properties in the XML configuration:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-pom-authentication-command-line.xml[tags=docker]
+include::example$packaging-oci-image/docker-pom-authentication-command-line.xml[tags=docker]
 ----
 
 
 
 [[build-image.examples.caches]]
 === Builder Cache and Workspace Configuration
+
 The CNB builder caches layers that are used when building and launching an image.
 By default, these caches are stored as named volumes in the Docker daemon with names that are derived from the full name of the target image.
 If the image name changes frequently, for example when the project version is used as a tag in the image name, then the caches can be invalidated frequently.
 
 The cache volumes can be configured to use alternative names to give more control over cache lifecycle as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/caches-pom.xml[tags=caches]
+include::example$packaging-oci-image/caches-pom.xml[tags=caches]
 ----
 
 Builders and buildpacks need a location to store temporary files during image building.
@@ -452,9 +463,9 @@ By default, this temporary build workspace is stored in a named volume.
 
 The caches and the build workspace can be configured to use bind mounts instead of named volumes, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/bind-caches-pom.xml[tags=caches]
+include::example$packaging-oci-image/bind-caches-pom.xml[tags=caches]
 ----
 
 
@@ -466,28 +477,30 @@ include::../maven/packaging-oci-image/bind-caches-pom.xml[tags=caches]
 
 [[build-image.examples.docker.minikube]]
 ==== Docker Configuration for minikube
+
 The plugin can communicate with the https://minikube.sigs.k8s.io/docs/tasks/docker_daemon/[Docker daemon provided by minikube] instead of the default local connection.
 
 On Linux and macOS, environment variables can be set using the command `eval $(minikube docker-env)` after minikube has been started.
 
 The plugin can also be configured to use the minikube daemon by providing connection details similar to those shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-minikube-pom.xml[tags=docker-minikube]
+include::example$packaging-oci-image/docker-minikube-pom.xml[tags=docker-minikube]
 ----
 
 
 
 [[build-image.examples.docker.podman]]
 ==== Docker Configuration for podman
+
 The plugin can communicate with a https://podman.io/[podman container engine].
 
 The plugin can be configured to use podman local connection by providing connection details similar to those shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-podman-pom.xml[tags=docker-podman]
+include::example$packaging-oci-image/docker-podman-pom.xml[tags=docker-podman]
 ----
 
 TIP: With the `colima` CLI installed, the command `podman info --format='{{.Host.RemoteSocket.Path}}'` can be used to get the value for the `docker.host` configuration property shown in this example.
@@ -496,30 +509,32 @@ TIP: With the `colima` CLI installed, the command `podman info --format='{{.Host
 
 [[build-image.examples.docker.colima]]
 ==== Docker Configuration for Colima
+
 The plugin can communicate with the Docker daemon provided by https://github.com/abiosoft/colima[Colima].
 The `DOCKER_HOST` environment variable can be set by using the command `export DOCKER_HOST=$(docker context inspect colima -f '{{.Endpoints.docker.Host}}').`
 
 The plugin can also be configured to use Colima daemon by providing connection details similar to those shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-colima-pom.xml[tags=docker-colima]
+include::example$packaging-oci-image/docker-colima-pom.xml[tags=docker-colima]
 ----
 
 
 
 [[build-image.examples.docker.auth]]
 ==== Docker Configuration for Authentication
+
 If the builder or run image are stored in a private Docker registry that supports user authentication, authentication details can be provided using `docker.builderRegistry` parameters as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-registry-authentication-pom.xml[tags=docker-registry-authentication]
+include::example$packaging-oci-image/docker-registry-authentication-pom.xml[tags=docker-registry-authentication]
 ----
 
 If the builder or run image is stored in a private Docker registry that supports token authentication, the token value can be provided using `docker.builderRegistry` parameters as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging-oci-image/docker-token-authentication-pom.xml[tags=docker-token-authentication]
+include::example$packaging-oci-image/docker-token-authentication-pom.xml[tags=docker-token-authentication]
 ----

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/build-info.adoc

@@ -1,12 +1,13 @@
 [[build-info]]
 = Integrating with Actuator
+
 Spring Boot Actuator displays build-related information if a `META-INF/build-info.properties` file is present.
 The `build-info` goal generates such file with the coordinates of the project and the build time.
 It also allows you to add an arbitrary number of additional properties, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/build-info/pom.xml[tags=build-info]
+include::example$build-info/pom.xml[tags=build-info]
 ----
 
 This configuration will generate a `build-info.properties` at the expected location with three additional keys.
@@ -14,4 +15,4 @@ This configuration will generate a `build-info.properties` at the expected locat
 NOTE: `java.version` is expected to be a regular property available in the project.
 It will be interpolated as you would expect.
 
-include::goals/build-info.adoc[leveloffset=+1]
+include::partial$goals/build-info.adoc[leveloffset=+1]

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/getting-started.adoc

@@ -1,15 +1,16 @@
 [[getting-started]]
 = Getting Started
+
 To use the Spring Boot Maven Plugin, include the appropriate XML in the `plugins` section of your `pom.xml`, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/getting-started/pom.xml[tags=getting-started]
+include::example$getting-started/pom.xml[tags=getting-started]
 ----
 
 If you use a milestone or snapshot release, you also need to add the appropriate `pluginRepository` elements, as shown in the following listing:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/getting-started/plugin-repositories-pom.xml[tags=plugin-repositories]
+include::example$getting-started/plugin-repositories-pom.xml[tags=plugin-repositories]
 ----

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/goals.adoc

@@ -1,5 +1,6 @@
 [[goals]]
 = Goals
+
 The Spring Boot Plugin has the following goals:
 
-include::goals/overview.adoc[]
+include::partial$goals/overview.adoc[]

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/help.adoc

@@ -2,4 +2,4 @@
 = Help Information
 The `help` goal is a standard goal that  displays information on the capabilities of the plugin.
 
-include::goals/help.adoc[leveloffset=+1]
+include::partial$goals/help.adoc[leveloffset=+1]

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/index.adoc

@@ -1,4 +1,9 @@
-[[introduction]]
-= Introduction
+[[maven-plugin]]
+= Maven Plugin
+
 The Spring Boot Maven Plugin provides Spring Boot support in https://maven.org[Apache Maven].
 It allows you to package executable jar or war archives, run Spring Boot applications, generate build information and start your Spring Boot application prior to running integration tests.
+
+To use it, you must use Maven 3.6.3 or later.
+
+In addition to this user guide, xref:api/java/index.html[API documentation] is also available.

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/integration-tests.adoc

@@ -1,37 +1,39 @@
 [[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:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/integration-tests/pom.xml[tags=integration-tests]
+include::example$integration-tests/pom.xml[tags=integration-tests]
 ----
 
 Such setup can now use the https://maven.apache.org/surefire/maven-failsafe-plugin[failsafe-plugin] to run your integration tests as you would expect.
 
 NOTE: The application is started in a separate process and JMX is used to communicate with the application.
 By default, the plugin uses port `9001`.
-If you need to configure the JMX port, see <<integration-tests.examples.jmx-port,the dedicated example>>.
+If you need to configure the JMX port, see xref:integration-tests.adoc#integration-tests.examples.jmx-port[the dedicated example].
 
-You could also configure a more advanced setup to skip the integration tests when a specific property has been set, see <<integration-tests.examples.skip,the dedicated example>>.
+You could also configure a more advanced setup to skip the integration tests when a specific property has been set, see xref:integration-tests.adoc#integration-tests.examples.skip[the dedicated example].
 
 
 
 [[integration-tests.no-starter-parent]]
 == Using Failsafe Without Spring Boot's Parent POM
+
 Spring Boot's Parent POM, `spring-boot-starter-parent`, configures Failsafe's `<classesDirectory>` to be `${project.build.outputDirectory}`.
 Without this configuration, which causes Failsafe to use the compiled classes rather than the repackaged jar, Failsafe cannot load your application's classes.
 If you are not using the parent POM, you should configure Failsafe in the same way, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/integration-tests/failsafe-pom.xml[tags=failsafe]
+include::example$integration-tests/failsafe-pom.xml[tags=failsafe]
 ----
 
-include::goals/start.adoc[leveloffset=+1]
+include::partial$goals/start.adoc[leveloffset=+1]
 
-include::goals/stop.adoc[leveloffset=+1]
+include::partial$goals/stop.adoc[leveloffset=+1]
 
 
 
@@ -42,14 +44,15 @@ include::goals/stop.adoc[leveloffset=+1]
 
 [[integration-tests.examples.random-port]]
 === Random Port for Integration Tests
+
 One nice feature of the Spring Boot test integration is that it can allocate a free port for the web application.
 When the `start` goal of the plugin is used, the Spring Boot application is started separately, making it difficult to pass the actual port to the integration test itself.
 
 The example below showcases how you could achieve the same feature using the https://www.mojohaus.org/build-helper-maven-plugin[Build Helper Maven Plugin]:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/integration-tests/random-port-pom.xml[tags=random-port]
+include::example$integration-tests/random-port-pom.xml[tags=random-port]
 ----
 
 You can now retrieve the `test.server.port` system property in any of your integration test to create a proper `URL` to the server.
@@ -58,13 +61,14 @@ You can now retrieve the `test.server.port` system property in any of your integ
 
 [[integration-tests.examples.jmx-port]]
 === Customize JMX port
+
 The `jmxPort` property allows to customize the port the plugin uses to communicate with the Spring Boot application.
 
 This example shows how you can customize the port in case `9001` is already used:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/integration-tests/customize-jmx-port-pom.xml[tags=customize-jmx-port]
+include::example$integration-tests/customize-jmx-port-pom.xml[tags=customize-jmx-port]
 ----
 
 TIP: If you need to configure the JMX port, make sure to do so in the global configuration as shown above so that it is shared by both goals.
@@ -73,18 +77,19 @@ TIP: If you need to configure the JMX port, make sure to do so in the global con
 
 [[integration-tests.examples.skip]]
 === Skip Integration Tests
+
 The `skip` property allows to skip the execution of the Spring Boot maven plugin altogether.
 
 This example shows how you can skip integration tests with a command-line property and still make sure that the `repackage` goal runs:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/integration-tests/skip-integration-tests-pom.xml[tags=skip-integration-tests]
+include::example$integration-tests/skip-integration-tests-pom.xml[tags=skip-integration-tests]
 ----
 
 By default, the integration tests will run but this setup allows you to easily disable them on the command-line as follows:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn verify -Dskip.it=true
+$ mvn verify -Dskip.it=true
 ----

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/packaging.adoc

@@ -1,18 +1,19 @@
 [[packaging]]
 = 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 an executable archive is performed by the `repackage` goal, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/repackage-pom.xml[tags=repackage]
+include::example$packaging/repackage-pom.xml[tags=repackage]
 ----
 
 TIP: If you are using `spring-boot-starter-parent`, such execution is already pre-configured with a `repackage` execution ID so that only the plugin definition should be added.
 
 The example above repackages a `jar` or `war` archive that is built during the package phase of the Maven lifecycle, including any `provided` dependencies that are defined in the project.
-If some of these dependencies need to be excluded, you can use one of the `exclude` options; see the <<packaging.examples.exclude-dependency,dependency exclusion>> for more details.
+If some of these dependencies need to be excluded, you can use one of the `exclude` options; see the xref:packaging.adoc#packaging.examples.exclude-dependency[dependency exclusion] for more details.
 
 The original (that is non-executable) artifact is renamed to `.original` by default but it is also possible to keep the original artifact using a custom classifier.
 
@@ -25,9 +26,9 @@ The plugin rewrites your manifest, and in particular it manages the `Main-Class`
 If the defaults don't work you have to configure the values in the Spring Boot plugin, not in the jar plugin.
 The `Main-Class` in the manifest is controlled by the `layout` property of the Spring Boot plugin, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/non-default-pom.xml[tags=non-default]
+include::example$packaging/non-default-pom.xml[tags=non-default]
 ----
 
 The `layout` property defaults to a value determined by the archive type (`jar` or `war`). The following layouts are available:
@@ -41,6 +42,7 @@ The `layout` property defaults to a value determined by the archive type (`jar`
 
 [[packaging.layers]]
 == Layered Jar or War
+
 A repackaged jar contains the application's classes and dependencies in `BOOT-INF/classes` and `BOOT-INF/lib` respectively.
 Similarly, an executable war contains the application's classes in `WEB-INF/classes` and dependencies in `WEB-INF/lib` and `WEB-INF/lib-provided`.
 For cases where a docker image needs to be built from the contents of a jar or war, it's useful to be able to separate these directories further so that they can be written into distinct layers.
@@ -64,29 +66,30 @@ Content that is least likely to change should be added first, followed by layers
 The repackaged archive includes the `layers.idx` file by default.
 To disable this feature, you can do so in the following manner:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/disable-layers-pom.xml[tags=disable-layers]
+include::example$packaging/disable-layers-pom.xml[tags=disable-layers]
 ----
 
 
 
 [[packaging.layers.configuration]]
 === Custom Layers Configuration
+
 Depending on your application, you may want to tune how layers are created and add new ones.
 This can be done using a separate configuration file that should be registered as shown below:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/custom-layers-pom.xml[tags=custom-layers]
+include::example$packaging/custom-layers-pom.xml[tags=custom-layers]
 ----
 
 The configuration file describes how an archive can be separated into layers, and the order of those layers.
 The following example shows how the default ordering described above can be defined explicitly:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/layers.xml[tags=layers]
+include::example$packaging/layers.xml[tags=layers]
 ----
 
 The `layers` XML format is defined in three sections:
@@ -119,7 +122,7 @@ Then claiming any remaining classes and resources for the `application` layer.
 NOTE: The order that `<into>` blocks are defined is often different from the order that the layers are written.
 For this reason the `<layerOrder>` element must always be included and _must_ cover all layers referenced by the `<into>` blocks.
 
-include::goals/repackage.adoc[leveloffset=+1]
+include::partial$goals/repackage.adoc[leveloffset=+1]
 
 
 
@@ -130,23 +133,24 @@ include::goals/repackage.adoc[leveloffset=+1]
 
 [[packaging.examples.custom-classifier]]
 === Custom Classifier
+
 By default, the `repackage` goal replaces the original artifact with the repackaged one.
 That is a sane behavior for modules that represent an application but if your module is used as a dependency of another module, you need to provide a classifier for the repackaged one.
 The reason for that is that application classes are packaged in `BOOT-INF/classes` so that the dependent module cannot load a repackaged jar's classes.
 
 If that is the case or if you prefer to keep the original artifact and attach the repackaged one with a different classifier, configure the plugin as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/different-classifier-pom.xml[tags=different-classifier]
+include::example$packaging/different-classifier-pom.xml[tags=different-classifier]
 ----
 
 If you are using `spring-boot-starter-parent`, the `repackage` goal is executed automatically in an execution with id `repackage`.
 In that setup, only the configuration should be specified, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/repackage-configuration-pom.xml[tags=repackage-configuration]
+include::example$packaging/repackage-configuration-pom.xml[tags=repackage-configuration]
 ----
 
 This configuration will generate two artifacts: the original one and the repackaged counter part produced by the repackage goal.
@@ -155,28 +159,29 @@ Both will be installed/deployed transparently.
 You can also use the same configuration if you want to repackage a secondary artifact the same way the main artifact is replaced.
 The following configuration installs/deploys a single `task` classified artifact with the repackaged application:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/classified-artifact-pom.xml[tags=classified-artifact]
+include::example$packaging/classified-artifact-pom.xml[tags=classified-artifact]
 ----
 
 As both the `maven-jar-plugin` and the `spring-boot-maven-plugin` runs at the same phase, it is important that the jar plugin is defined first (so that it runs before the repackage goal).
 Again, if you are using `spring-boot-starter-parent`, this can be simplified as follows:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/jar-plugin-first-pom.xml[tags=jar-plugin-first]
+include::example$packaging/jar-plugin-first-pom.xml[tags=jar-plugin-first]
 ----
 
 
 
 [[packaging.examples.custom-name]]
 === Custom Name
+
 If you need the repackaged jar to have a different local name than the one defined by the `artifactId` attribute of the project, use the standard `finalName`, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/custom-name-pom.xml[tags=custom-name]
+include::example$packaging/custom-name-pom.xml[tags=custom-name]
 ----
 
 This configuration will generate the repackaged artifact in `target/my-app.jar`.
@@ -185,12 +190,13 @@ This configuration will generate the repackaged artifact in `target/my-app.jar`.
 
 [[packaging.examples.local-artifact]]
 === Local Repackaged Artifact
+
 By default, the `repackage` goal replaces the original artifact with the executable one.
 If you need to only deploy the original jar and yet be able to run your app with the regular file name, configure the plugin as follows:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/local-repackaged-artifact-pom.xml[tags=local-repackaged-artifact]
+include::example$packaging/local-repackaged-artifact-pom.xml[tags=local-repackaged-artifact]
 ----
 
 This configuration generates two artifacts: the original one and the executable counter part produced by the `repackage` goal.
@@ -200,11 +206,12 @@ Only the original one will be installed/deployed.
 
 [[packaging.examples.custom-layout]]
 === Custom Layout
+
 Spring Boot repackages the jar file for this project using a custom layout factory defined in the additional jar file, provided as a dependency to the build plugin:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/custom-layout-pom.xml[tags=custom-layout]
+include::example$packaging/custom-layout-pom.xml[tags=custom-layout]
 ----
 
 The layout factory is provided as an implementation of `LayoutFactory` (from `spring-boot-loader-tools`) explicitly specified in the pom.
@@ -216,6 +223,7 @@ Layout factories are always ignored if an explicit <<packaging.repackage-goal.pa
 
 [[packaging.examples.exclude-dependency]]
 === Dependency Exclusion
+
 By default, both the `repackage` and the `run` goals will include any `provided` dependencies that are defined in the project.
 A Spring Boot project should consider `provided` dependencies as "container" dependencies that are required to run the application.
 Generally speaking, Spring Boot projects are not used as dependencies and are therefore unlikely to have any `optional` dependencies.
@@ -231,42 +239,44 @@ There are two ways one can exclude a dependency from being packaged/used at runt
 
 The following example excludes `com.example:module1`, and only that artifact:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/exclude-artifact-pom.xml[tags=exclude-artifact]
+include::example$packaging/exclude-artifact-pom.xml[tags=exclude-artifact]
 ----
 
 This example excludes any artifact belonging to the `com.example` group:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/exclude-artifact-group-pom.xml[tags=exclude-artifact-group]
+include::example$packaging/exclude-artifact-group-pom.xml[tags=exclude-artifact-group]
 ----
 
 
 
 [[packaging.examples.layered-archive-tools]]
 === Layered Archive Tools
+
 When a layered jar or war is created, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your archive.
 With this jar on the classpath, you can launch your application in a special mode which allows the bootstrap code to run something entirely different from your application, for example, something that extracts the layers.
 If you wish to exclude this dependency, you can do so in the following manner:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/exclude-dependency-pom.xml[tags=exclude-dependency]
+include::example$packaging/exclude-dependency-pom.xml[tags=exclude-dependency]
 ----
 
 
 
 [[packaging.examples.custom-layers-configuration]]
 === Custom Layers Configuration
+
 The default setup splits dependencies into snapshot and non-snapshot, however, you may have more complex rules.
 For example, you may want to isolate company-specific dependencies of your project in a dedicated layer.
 The following `layers.xml` configuration shown one such setup:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/packaging/layers-configuration.xml[tags=layers-configuration]
+include::example$packaging/layers-configuration.xml[tags=layers-configuration]
 ----
 
 The configuration above creates an additional `company-dependencies` layer with all libraries with the `com.acme` groupId.

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/run.adoc

@@ -1,26 +1,27 @@
 [[run]]
 = Running your Application with Maven
+
 The plugin includes a run goal which can be used to launch your application from the command line, as shown in the following example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run
+$ mvn spring-boot:run
 ----
 
-Application arguments can be specified using the `arguments` parameter, see <<run.examples.using-application-arguments,using application arguments>> for more details.
+Application arguments can be specified using the `arguments` parameter, see xref:run#run.examples.using-application-arguments[using application arguments] for more details.
 
 The application is executed in a forked process and setting properties on the command-line will not affect the application.
-If you need to specify some JVM arguments (that is for debugging purposes), you can use the `jvmArguments` parameter, see <<run.examples.debug,Debug the application>> for more details.
-There is also explicit support for <<run.examples.system-properties,system properties>> and <<run.examples.environment-variables,environment variables>>.
+If you need to specify some JVM arguments (that is for debugging purposes), you can use the `jvmArguments` parameter, see xref:run#run.examples.debug[Debug the application] for more details.
+There is also explicit support for xref:run#run.examples.system-properties[system properties] and xref:run#run.examples.environment-variables[environment variables].
 
-As enabling a profile is quite common, there is dedicated `profiles` property that offers a shortcut for `-Dspring-boot.run.jvmArguments="-Dspring.profiles.active=dev"`, see <<run.examples.specify-active-profiles,Specify active profiles>>.
+As enabling a profile is quite common, there is dedicated `profiles` property that offers a shortcut for `-Dspring-boot.run.jvmArguments="-Dspring.profiles.active=dev"`, see xref:run#run.examples.specify-active-profiles[Specify active profiles].
 
 Spring Boot `devtools` is a module to improve the development-time experience when working on Spring Boot applications.
 To enable it, just add the following dependency to your project:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/running/devtools-pom.xml[tags=devtools]
+include::example$running/devtools-pom.xml[tags=devtools]
 ----
 
 When `devtools` is running, it detects change when you recompile your application and automatically refreshes it.
@@ -30,17 +31,17 @@ It also provides a LiveReload server so that it can automatically trigger a brow
 Devtools can also be configured to only refresh the browser whenever a static resource has changed (and ignore any change in the code).
 Just include the following property in your project:
 
-[source,properties,indent=0]
+[source,properties]
 ----
-	spring.devtools.remote.restart.enabled=false
+spring.devtools.remote.restart.enabled=false
 ----
 
 Prior to `devtools`, the plugin supported hot refreshing of resources by default which has now be disabled in favour of the solution described above.
 You can restore it at any time by configuring your project:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,subs="verbatim,attributes"]
 ----
-include::../maven/running/hot-refresh-pom.xml[tags=hot-refresh]
+include::example$running/hot-refresh-pom.xml[tags=hot-refresh]
 ----
 
 When `addResources` is enabled, any `src/main/resources` directory will be added to the application classpath when you run the application and any duplicate found in the classes output will be removed.
@@ -51,15 +52,15 @@ It is also a helpful way of allowing your front end developers to work without n
 NOTE: A side effect of using this feature is that filtering of resources at build time will not work.
 
 In order to be consistent with the `repackage` goal, the `run` goal builds the classpath in such a way that any dependency that is excluded in the plugin's configuration gets excluded from the classpath as well.
-For more details, see <<packaging.examples.exclude-dependency,the dedicated example>>.
+For more details, see xref:packaging.adoc#packaging.examples.exclude-dependency[the dedicated example].
 
 Sometimes it is useful to run a test variant of your application.
-For example, if you want to {spring-boot-reference}/#features.testing.testcontainers.at-development-time[use Testcontainers at development time] or make use of some test stubs.
+For example, if you want to xref:reference:features/testcontainers.adoc#features.testcontainers.at-development-time[use Testcontainers at development time] or make use of some test stubs.
 Use the `test-run` goal with many of the same features and configuration options as `run` for this purpose.
 
-include::goals/run.adoc[leveloffset=+1]
+include::partial$goals/run.adoc[leveloffset=+1]
 
-include::goals/test-run.adoc[leveloffset=+1]
+include::partial$goals/test-run.adoc[leveloffset=+1]
 
 
 
@@ -70,32 +71,34 @@ include::goals/test-run.adoc[leveloffset=+1]
 
 [[run.examples.debug]]
 === Debug the Application
+
 The `run` and `test-run` goals run your application in a forked process.
 If you need to debug it, you should add the necessary JVM arguments to enable remote debugging.
 The following configuration suspend the process until a debugger has joined on port 5005:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/running/debug-pom.xml[tags=debug]
+include::example$running/debug-pom.xml[tags=debug]
 ----
 
 These arguments can be specified on the command line as well:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run -Dspring-boot.run.jvmArguments=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005
+$ mvn spring-boot:run -Dspring-boot.run.jvmArguments=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005
 ----
 
 
 
 [[run.examples.system-properties]]
 === Using System Properties
+
 System properties can be specified using the `systemPropertyVariables` attribute.
 The following example sets `property1` to `test` and `property2` to 42:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/running/system-properties-pom.xml[tags=system-properties]
+include::example$running/system-properties-pom.xml[tags=system-properties]
 ----
 
 If the value is empty or not defined (that is `<my-property/`>), the system property is set with an empty String as the value.
@@ -107,21 +110,22 @@ Any attempt to pass any other Maven variable type (for example a `List` or a `UR
 The `jvmArguments` parameter takes precedence over system properties defined with the mechanism above.
 In the following example, the value for `property1` is `overridden`:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dproperty1=overridden"
+$ mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dproperty1=overridden"
 ----
 
 
 
 [[run.examples.environment-variables]]
 === Using Environment Variables
+
 Environment variables can be specified using the `environmentVariables` attribute.
 The following example sets the 'ENV1', 'ENV2', 'ENV3', 'ENV4' env variables:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/running/environment-variables-pom.xml[tags=environment-variables]
+include::example$running/environment-variables-pom.xml[tags=environment-variables]
 ----
 
 If the value is empty or not defined (that is `<MY_ENV/`>), the env variable is set with an empty String as the value.
@@ -136,39 +140,41 @@ Environment variables defined this way take precedence over existing values.
 
 [[run.examples.using-application-arguments]]
 === Using Application Arguments
+
 Application arguments can be specified using the `arguments` attribute.
 The following example sets two arguments: `property1` and `property2=42`:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/running/application-arguments-pom.xml[tags=application-arguments]
+include::example$running/application-arguments-pom.xml[tags=application-arguments]
 ----
 
 On the command-line, arguments are separated by a space the same way `jvmArguments` are.
 If an argument contains a space, make sure to quote it.
 In the following example, two arguments are available: `property1` and `property2=Hello World`:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run -Dspring-boot.run.arguments="property1 'property2=Hello World'"
+$ mvn spring-boot:run -Dspring-boot.run.arguments="property1 'property2=Hello World'"
 ----
 
 
 
 [[run.examples.specify-active-profiles]]
 === Specify Active Profiles
+
 The active profiles to use for a particular application can be specified using the `profiles` argument.
 
 The following configuration enables the `local` and `dev` profiles:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/running/active-profiles-pom.xml[tags=active-profiles]
+include::example$running/active-profiles-pom.xml[tags=active-profiles]
 ----
 
 The profiles to enable can be specified on the command line as well, make sure to separate them with a comma, as shown in the following example:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run -Dspring-boot.run.profiles=local,dev
+$ mvn spring-boot:run -Dspring-boot.run.profiles=local,dev
 ----

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/pages/using.adoc

@@ -1,5 +1,6 @@
 [[using]]
 = Using the Plugin
+
 Maven users can inherit from the `spring-boot-starter-parent` project to obtain sensible defaults.
 The parent project provides the following features:
 
@@ -36,18 +37,21 @@ and then configure the source and the target options instead:
 ----
 ====
 
+
+
 [[using.parent-pom]]
 == Inheriting the Starter Parent POM
+
 To configure your project to inherit from the `spring-boot-starter-parent`, set the `parent` as follows:
 
-[source,xml,indent=0,subs="verbatim,quotes,attributes"]
+[source,xml,subs="verbatim,quotes,attributes"]
 ----
-	<!-- Inherit defaults from Spring Boot -->
-	<parent>
-		<groupId>org.springframework.boot</groupId>
-		<artifactId>spring-boot-starter-parent</artifactId>
-		<version>{gradle-project-version}</version>
-	</parent>
+<!-- Inherit defaults from Spring Boot -->
+<parent>
+	<groupId>org.springframework.boot</groupId>
+	<artifactId>spring-boot-starter-parent</artifactId>
+	<version>{version-spring-boot}</version>
+</parent>
 ----
 
 NOTE: You should need to specify only the Spring Boot version number on this dependency.
@@ -56,60 +60,62 @@ If you import additional starters, you can safely omit the version number.
 With that setup, you can also override individual dependencies by overriding a property in your own project.
 For instance, to use a different version of the SLF4J library and the Spring Data release train, you would add the following to your `pom.xml`:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/using/different-versions-pom.xml[tags=different-versions]
+include::example$using/different-versions-pom.xml[tags=different-versions]
 ----
 
-Browse the {version-properties-appendix}[`Dependency versions Appendix`] in the Spring Boot reference for a complete list of dependency version properties.
+Browse the xref:appendix:dependency-versions/properties.adoc[Dependency Versions Properties] section in the Spring Boot reference for a complete list of dependency version properties.
 
 
 
 [[using.import]]
 == Using Spring Boot without the Parent POM
+
 There may be reasons for you not to inherit from the `spring-boot-starter-parent` POM.
 You may have your own corporate standard parent that you need to use or you may prefer to explicitly declare all your Maven configuration.
 
 If you do not want to use the `spring-boot-starter-parent`, you can still keep the benefit of the dependency management (but not the plugin management) by using an `import` scoped dependency, as follows:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/using/no-starter-parent-pom.xml[tags=no-starter-parent]
+include::example$using/no-starter-parent-pom.xml[tags=no-starter-parent]
 ----
 
 The preceding sample setup does not let you override individual dependencies by using properties, as explained above.
 To achieve the same result, you need to add entries in the `dependencyManagement` section of your project **before** the `spring-boot-dependencies` entry.
 For instance, to use a different version of the SLF4J library and the Spring Data release train, you could add the following elements to your `pom.xml`:
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/using/no-starter-parent-override-dependencies-pom.xml[tags=no-starter-parent-override-dependencies]
+include::example$using/no-starter-parent-override-dependencies-pom.xml[tags=no-starter-parent-override-dependencies]
 ----
 
 
 
 [[using.overriding-command-line]]
 == Overriding settings on the command-line
+
 The plugin offers a number of user properties, starting with `spring-boot`, to let you customize the configuration from the command-line.
 
 For instance, you could tune the profiles to enable when running the application as follows:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run -Dspring-boot.run.profiles=dev,local
+$ mvn spring-boot:run -Dspring-boot.run.profiles=dev,local
 ----
 
 If you want to both have a default while allowing it to be overridden on the command-line, you should use a combination of a user-provided project property and MOJO configuration.
 
-[source,xml,indent=0,subs="verbatim,attributes",tabsize=4]
+[source,xml,indent=0,subs="verbatim,attributes"]
 ----
-include::../maven/using/default-and-override-pom.xml[tags=default-and-override]
+include::example$using/default-and-override-pom.xml[tags=default-and-override]
 ----
 
 The above makes sure that `local` and `dev` are enabled by default.
 Now a dedicated property has been exposed, this can be overridden on the command-line as well:
 
-[indent=0]
+[source,shell]
 ----
-	$ mvn spring-boot:run -Dapp.profiles=test
+$ mvn spring-boot:run -Dapp.profiles=test
 ----

spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/antora/modules/maven-plugin/partials/nav-maven-plugin.adoc

@@ -0,0 +1,11 @@
+* xref:maven-plugin:index.adoc[]
+** xref:maven-plugin:getting-started.adoc[]
+** xref:maven-plugin:using.adoc[]
+** xref:maven-plugin:goals.adoc[]
+** xref:maven-plugin:packaging.adoc[]
+** xref:maven-plugin:build-image.adoc[]
+** xref:maven-plugin:run.adoc[]
+** xref:maven-plugin:aot.adoc[]
+** xref:maven-plugin:integration-tests.adoc[]
+** xref:maven-plugin:build-info.adoc[]
+** xref:maven-plugin:help.adoc[]

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

@@ -1,46 +0,0 @@
-[[spring-boot-maven-plugin-documentation]]
-= Spring Boot Maven Plugin Documentation
-Stephane Nicoll; Andy Wilkinson; Scott Frederick; Moritz Halbritter
-v{gradle-project-version}
-:!version-label:
-:doctype: book
-:toc: left
-:toclevels: 4
-:numbered:
-:sectanchors:
-:icons: font
-:hide-uri-scheme:
-:docinfo: shared,private
-:attribute-missing: warn
-:buildpacks-reference: https://buildpacks.io/docs
-:nbt-reference: https://graalvm.github.io/native-build-tools/latest/maven-plugin.html
-:spring-boot-docs: https://docs.spring.io/spring-boot/docs/{gradle-project-version}
-:spring-boot-api: {spring-boot-docs}/api/org/springframework/boot
-:spring-boot-reference: {spring-boot-docs}/reference/htmlsingle
-:version-properties-appendix: {spring-boot-reference}/#dependency-versions-properties
-:paketo-reference: https://paketo.io/docs
-:paketo-java-reference: {paketo-reference}/buildpacks/language-family-buildpacks/java
-
-
-
-include::introduction.adoc[leveloffset=+1]
-
-include::getting-started.adoc[leveloffset=+1]
-
-include::using.adoc[leveloffset=+1]
-
-include::goals.adoc[leveloffset=+1]
-
-include::packaging.adoc[leveloffset=+1]
-
-include::packaging-oci-image.adoc[leveloffset=+1]
-
-include::running.adoc[leveloffset=+1]
-
-include::aot.adoc[leveloffset=+1]
-
-include::integration-tests.adoc[leveloffset=+1]
-
-include::build-info.adoc[leveloffset=+1]
-
-include::help.adoc[leveloffset=+1]