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, spring-boot-loader, snapshot-dependencies, application. Content that is least ike to change should be added first, followed by layers that are more likely to change.
Custom Layers Configuration
The following example shows how the default ordering described above can be defined explicitly:
<layers xmlns=”http://www.springframework.org/schema/boot/layers”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
Xsk:schemaLocation=”http://www.springframework.org/schema/boot/layers
https://www.springframework.org/schema/boot/layers/layers-2.4.xsd”>
<application>
<into layer=”spring-boot-loader”>
<include>org/springframework/boot/loader/**</include>
</into>
<into layer=”application” />
</application>
<dependencies>
<into layer=”application”>
<includeModuleDependencies />
</into>
<into layer=”snapshot-dependencies”>
<include>*:*:*SNAPSHOT</include>
</into>
<inot layer=”dependencies” />
<dependencies>
<layerOrder>
<layer>dependencies</layer>
<layer>spring-boot-loader</layer>
<layer>snapshot-dependencies</layer>
<layer>application</layer>
</layerOrder>
</layers>
The layers
XML format is defined in three sections:
- The
<application>
block defines how the application classes and resources should be layered. - The
<dependencies>
block defines how dependencies should be layered. - The
<layerOrder>
block defines the order that the layers should be written.
The <into>
block claims content using nested <include>
and <exclude>
elements. The <application>
section uses Ant-style patch matching for include/exclude expressions. The <dependencies>
section uses group:artifact[:version]
patterns. It also provides <includeModuleDependencies />
and <excludeModuleDependencies />
elements that can be used to include or exclude local module dependencies.
If no <include>
is defined, then all content(not claimed by and earlier block) is considered.
If no <exclude>
is defined, then no exclusions are applied.
Looking at the <dependencies>
example above, we can see that the first <into>
will claim all module dependencies for the application.layer. The next <into>
will claim all SNAPSHOT dependencies for the snapshot-dependencies
layer. The final <into>
will claim anything left for dependencies
layer.
The <application>
block has similar rules. First claiming org/springframework/boot/loader/**
content for the spring-boot-loader
layer. Then claiming any remaining classes and resource for the application
layer.