Update Maven and Gradle layer customization docs

Update the Maven and Gradle documentation following the refined
layer customization changes.

See gh-20526

spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc

@@ -8031,7 +8031,7 @@ For Gradle, refer to the {spring-boot-gradle-plugin-docs}/#packaging-layered-jar
 
 
 === Writing the Dockerfile
-When you create a layered jar, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
+When you create a jar containing the layers index file, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
 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.
 Here’s how you can launch your jar with a `layertools` jar mode:
 

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

@@ -265,7 +265,9 @@ include::../gradle/packaging/boot-war-properties-launcher.gradle.kts[tags=proper
 [[packaging-layered-jars]]
 ==== Packaging layered jars
 By default, the `bootJar` task 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.
+For cases where a docker image needs to be built from the contents of the jar, it's useful to be able to separate these folders futher so that they can be written into distinct layers.
+
+Layered jars use the same layout as regular boot packaged jars, but include an additional meta-data file that describes each layer.
 To use this feature, the layering feature must be enabled:
 
 [source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
@@ -280,14 +282,15 @@ include::../gradle/packaging/boot-jar-layered.gradle[tags=layered]
 include::../gradle/packaging/boot-jar-layered.gradle.kts[tags=layered]
 ----
 
-By default, the following layers are created:
+By default, the following layers are defined:
 
 * `dependencies` for any dependency whose version does not contain `SNAPSHOT`.
+* `spring-boot-loader` for the jar loader classes.
 * `snapshot-dependencies` for any dependency whose version contains `SNAPSHOT`.
 * `application` for application classes and resources.
 
 The layers order is important as it determines how likely previous layers can be cached when part of the application changes.
-The default order is `dependencies`, `snapshot-dependencies`, and `application`.
+The default order is `dependencies`, `spring-boot-loader`, `snapshot-dependencies`, `application`.
 Content that is least likely to change should be added first, followed by layers that are more likely to change.
 
 When you create a layered jar, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
@@ -311,9 +314,9 @@ include::../gradle/packaging/boot-jar-layered-exclude-tools.gradle.kts[tags=laye
 [[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 configuration that lists the layers and their order as well as the strategies to apply to libraries and classes.
 
-The following example shows what the implicit layer configuration described above does:
+This can be done using configuration that describes how the jar can be separated into layers, and the order of those layers.
+The following example shows how the default ordering described above can be defined explicity:
 
 [source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
 .Groovy
@@ -327,12 +330,30 @@ include::../gradle/packaging/boot-jar-layered-custom.gradle[tags=layered]
 include::../gradle/packaging/boot-jar-layered-custom.gradle.kts[tags=layered]
 ----
 
-Each `layerContent` closure defines a strategy to include or exclude an entry of the jar in a layer.
-When an entry matches a strategy, it is included in the layer and further strategies are ignored.
-This is illustrated by the `dependencies` layer that has a "catch-all" include filter used to add any libraries that were not processed by previous strategies.
+The `layered` DSL is defined using three parts:
+
+* The `application` closure defines how the application classes and resources should be layered.
+* The `dependencies` closure defines how dependencies should be layered.
+* The `layerOrder` method defines the order that the layers should be written.
+
+Nested `intoLayer` closures are used within `application` and `dependencies` sections to claim content for a layer.
+These closures are evaluated in the order that they are defined, from top to bottom.
+Any content not claimed by an earlier `intoLayer` closure remains availble for subsequent ones to consider.
+
+The `intoLayer` closurer claims content using nested `include` and `exclude` calls.
+The `applicaton` closure uses Ant-style patch matching for include/exclude parameters.
+The `dependencies` section uses `group:artifact[:version]` patterns.
+
+If no `include` call is made, then all content (not claimed by an earlier closure) is considered.
+
+If no `exclude` call is made, then no exclusions are applied.
+
+Looking at the `dependencies` closure in the example above, we can see tha the first `intoLayer` will claim all SNAPSHOT dependencies for the `snapshot-dependencies` layer.
+The subsequent `intoLayer` will claim anything left (in this case, any dependency that is not a SNAPSHOT) for the `dependencies` layer.
 
-The content of a `libraries` layer can be customized using filters to `include` or `exclude` based on the dependency coordinates.
-The format is `groupId:artifactId[:version]`.
-In the example above, any artifact whose version ends with `SNAPSHOT` is going to be included in the `snapshot-dependencies` layer.
+The `application` closure has similar rules.
+First claiming `org/springframework/boot/loader/**` content for the `spring-boot-loader` layer.
+Then claiming any remaining classes and resources for the `application` layer.
 
-The content of an `application` layer can be customized using filters to `include` or `exclude` based on location of the entry using Ant-style pattern matching.
\ No newline at end of file
+NOTE: The order that `intoLayer` closures are added is often different from the order that the layers are written.
+For this reason the `layerOrder` method must always be called and _must_ cover all layers referenced by the `intoLayer` calls.

spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/gradle/packaging/boot-jar-layered-custom.gradle

@@ -11,6 +11,9 @@ bootJar {
 bootJar {
 	layered {
 		application {
+			intoLayer("spring-boot-loader") {
+				include "org/springframework/boot/loader/**"
+			}
 			intoLayer("application")
 		}
 		dependencies {
@@ -19,7 +22,7 @@ bootJar {
 			}
 			intoLayer("dependencies")
 		}
-		layerOrder "dependencies", "snapshot-dependencies", "application"
+		layerOrder "dependencies", "spring-boot-loader", "snapshot-dependencies", "application"
 	}
 }
 // end::layered[]

spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/gradle/packaging/boot-jar-layered-custom.gradle.kts

@@ -9,6 +9,9 @@ plugins {
 tasks.getByName<BootJar>("bootJar") {
 	layered {
 		application {
+			intoLayer("spring-boot-loader") {
+				include("org/springframework/boot/loader/**")
+			}
 			intoLayer("application")
 		}
 		dependencies {
@@ -17,7 +20,7 @@ tasks.getByName<BootJar>("bootJar") {
 			}
 			intoLayer("dependencies") {
 		}
-		layersOrder("dependencies", "snapshot-dependencies", "application")
+		layersOrder("dependencies", "spring-boot-loader", "snapshot-dependencies", "application")
 	}
 }
 // end::layered[]