You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc
+1-1
Original file line number
Diff line number
Diff line change
@@ -8031,7 +8031,7 @@ For Gradle, refer to the {spring-boot-gradle-plugin-docs}/#packaging-layered-jar
8031
8031
8032
8032
8033
8033
=== Writing the Dockerfile
8034
-
When you create a layered jar, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
8034
+
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.
8035
8035
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.
8036
8036
Here’s how you can launch your jar with a `layertools` jar mode:
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.
268
-
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.
268
+
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.
269
+
270
+
Layered jars use the same layout as regular boot packaged jars, but include an additional meta-data file that describes each layer.
269
271
To use this feature, the layering feature must be enabled:
Each `layerContent` closure defines a strategy to include or exclude an entry of the jar in a layer.
331
-
When an entry matches a strategy, it is included in the layer and further strategies are ignored.
332
-
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.
333
+
The `layered` DSL is defined using three parts:
334
+
335
+
* The `application` closure defines how the application classes and resources should be layered.
336
+
* The `dependencies` closure defines how dependencies should be layered.
337
+
* The `layerOrder` method defines the order that the layers should be written.
338
+
339
+
Nested `intoLayer` closures are used within `application` and `dependencies` sections to claim content for a layer.
340
+
These closures are evaluated in the order that they are defined, from top to bottom.
341
+
Any content not claimed by an earlier `intoLayer` closure remains availble for subsequent ones to consider.
342
+
343
+
The `intoLayer` closurer claims content using nested `include` and `exclude` calls.
344
+
The `applicaton` closure uses Ant-style patch matching for include/exclude parameters.
345
+
The `dependencies` section uses `group:artifact[:version]` patterns.
346
+
347
+
If no `include` call is made, then all content (not claimed by an earlier closure) is considered.
348
+
349
+
If no `exclude` call is made, then no exclusions are applied.
350
+
351
+
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.
352
+
The subsequent `intoLayer` will claim anything left (in this case, any dependency that is not a SNAPSHOT) for the `dependencies` layer.
333
353
334
-
The content of a `libraries` layer can be customized using filters to `include` or `exclude` based on the dependency coordinates.
335
-
The format is `groupId:artifactId[:version]`.
336
-
In the example above, any artifact whose version ends with `SNAPSHOT` is going to be included in the `snapshot-dependencies` layer.
354
+
The `application` closure has similar rules.
355
+
First claiming `org/springframework/boot/loader/**` content for the `spring-boot-loader` layer.
356
+
Then claiming any remaining classes and resources for the `application` layer.
337
357
338
-
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.
358
+
NOTE: The order that `intoLayer` closures are added is often different from the order that the layers are written.
359
+
For this reason the `layerOrder` method must always be called and _must_ cover all layers referenced by the `intoLayer` calls.
Copy file name to clipboardExpand all lines: spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/gradle/packaging/boot-jar-layered-custom.gradle
Copy file name to clipboardExpand all lines: spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/docs/gradle/packaging/boot-jar-layered-custom.gradle.kts
Copy file name to clipboardExpand all lines: spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging.adoc
+84-75
Original file line number
Diff line number
Diff line change
@@ -71,11 +71,14 @@ The `layout` property defaults to a guess based on the archive type (`jar` or `w
71
71
* `ZIP` (alias to `DIR`): similar to the `JAR` layout using `PropertiesLauncher`.
72
72
* `NONE`: Bundle all dependencies and project resources. Does not bundle a bootstrap loader.
73
73
74
+
75
+
74
76
[[repackage-layers]]
75
-
=== Layered jar
77
+
=== Layered jars
78
+
A repackaged jar contains the application's classes and dependencies in `BOOT-INF/classes` and `BOOT-INF/lib` respectively.
79
+
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.
76
80
77
-
By default, a repackaged jar contains the application's classes and dependencies in `BOOT-INF/classes` and `BOOT-INF/lib` respectively.
78
-
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.
81
+
Layered jars use the same layout as regular repackaged jars, but include an additional meta-data file that describes each layer.
79
82
To use this feature, the layering feature must be enabled:
80
83
81
84
[source,xml,indent=0,subs="verbatim,attributes"]
@@ -98,22 +101,23 @@ To use this feature, the layering feature must be enabled:
98
101
</project>
99
102
----
100
103
101
-
By default, the following layers are created:
104
+
By default, the following layers are defined:
102
105
103
106
* `dependencies` for any dependency whose version does not contain `SNAPSHOT`.
107
+
* `spring-boot-loader` for the jar loader classes.
104
108
* `snapshot-dependencies` for any dependency whose version contains `SNAPSHOT`.
105
109
* `application` for application classes and resources.
106
110
107
111
The layers order is important as it determines how likely previous layers can be cached when part of the application changes.
108
-
The default order is `dependencies`, `snapshot-dependencies`, and `application`.
112
+
The default order is `dependencies`, `spring-boot-loader`, `snapshot-dependencies`, `application`.
109
113
Content that is least likely to change should be added first, followed by layers that are more likely to change.
110
114
111
115
112
116
113
117
[[repackage-layers-configuration]]
114
118
==== Custom Layers configuration
115
119
Depending on your application, you may want to tune how layers are created and add new ones.
116
-
This can be done using a separate configuration file that should be registered as shown in the following example:
120
+
This can be done using a separate configuration file that should be registered as shown below:
117
121
118
122
[source,xml,indent=0,subs="verbatim,attributes"]
119
123
----
@@ -136,53 +140,64 @@ This can be done using a separate configuration file that should be registered a
136
140
</project>
137
141
----
138
142
139
-
The configuration file lists the layers and their order as well as the strategies to apply to libraries and classes.
140
-
The following example shows what the implicit layer configuration described above does:
143
+
The configuration file describes how the jar can be separated into layers, and the order of those layers.
144
+
The following example shows how the default ordering described above can be defined explicity:
Each `layer-content` element defines a strategy to include or exclude an entry of the jar in a layer.
176
-
When an entry matches a strategy, it is included in the layer and further strategies are ignored.
177
-
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.
178
173
179
-
The content of a `libraries` layer can be customized using filters to `include` or `exclude` based on the dependency coordinates.
180
-
The format is `groupId:artifactId[:version]`.
181
-
In the example above, any artifact whose version ends with `SNAPSHOT` is going to be included in the `snapshot-dependencies` layer.
174
+
The `layers` XML format is defined in three sections:
175
+
176
+
* The `<application>` block defines how the application classes and resources should be layered.
177
+
* The `<dependencies>` block defines how dependencies should be layered.
178
+
* The `<layerOrder>` block defines the order that the layers should be written.
179
+
180
+
Nested `<into>` blocks are used within `<application>` and `<dependencies>` sections to claim content for a layer.
181
+
The blocks are evaluated in the order that they are defined, from top to bottom.
182
+
Any content not claimed by an earlier block remains availble for subsequent blocks to consider.
183
+
184
+
The `<into>` block claims content using nested `<include>` and `<exclude>` elements.
185
+
The `<applicaton>` section uses Ant-style patch matching for include/exclude expressions.
186
+
The `<dependencies>` section uses `group:artifact[:version]` patterns.
182
187
183
-
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.
188
+
If no `<include>` is defined, then all content (not claimed by an earlier block) is considered.
184
189
190
+
If no `<exclude>` is defined, then no exclusions are applied.
185
191
192
+
Looking at the `<dependencies>` example above, we can see tha the first `<into>` will claim all SNAPSHOT dependencies for the `snapshot-dependencies` layer.
193
+
The subsequent `<into>` will claim anything left (in this case, any dependency that is not a SNAPSHOT) for the `dependencies` layer.
194
+
195
+
The `<application>` block has similar rules.
196
+
First claiming `org/springframework/boot/loader/**` content for the `spring-boot-loader` layer.
197
+
Then claiming any remaining classes and resources for the `application` layer.
198
+
199
+
NOTE: The order that `<into>` blocks are defined is often different from the order that the layers are written.
200
+
For this reason the `<layerOrder>` element must always be included and _must_ cover all layers referenced by the `<into>` blocks.
186
201
187
202
include::goals/repackage.adoc[leveloffset=+1]
188
203
@@ -515,7 +530,6 @@ This example excludes any artifact belonging to the `com.foo` group:
515
530
516
531
[[repackage-layered-jars-tools]]
517
532
==== Layered jar tools
518
-
519
533
When you create a layered jar, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
520
534
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.
521
535
If you wish to exclude this dependency, you can do so in the following manner:
@@ -545,44 +559,39 @@ If you wish to exclude this dependency, you can do so in the following manner:
545
559
546
560
[[repackage-layered-jars-additional-layers]]
547
561
==== Custom layers configuration
548
-
549
-
While the default setup creates two layers for libraries, you may want to isolate the dependencies of your project in a dedicated layer.
550
-
This allows to reuse the cache for external dependencies when an internal dependency has changed, as shown by the following example:
562
+
The default setup splits dependencies into snaphost and non-snapshot, however, you may have more complex rules.
563
+
For example, you may want to isolate company-specific dependencies of your project in a dedicated layer.
564
+
The following `layers.xml` configuration shown one such setup:
0 commit comments