Spring/spring-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Put module deps in app layer and make customization easier

Browse Source 
Previously, when building a layered jar with Maven, dependencies
on modules in the same build were treated the same as any other
dependency, being included in the dependencies or snapshot dependencies
layer based on their version.

This commit updates the default layering when using Maven to include
dependencies on modules in the same build in the application layer by
default. The XML schema has also been updated to allow the layer to be
customized using new <includeModuleDependencies/> and
<excludeModuleDependencies/> elements rather than relying on including
and excluding them via a group:artifact:version pattern.

Closes gh-23463
This commit is contained in:
Andy Wilkinson
2020-10-20 11:13:23 +01:00
parent 5b49986f3b
commit 3bfe1b00b5
17 changed files with 314 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -86,7 +86,10 @@ 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.
* `application` for local module dependencies, application classes, and resources.
Module dependencies are identified by looking at all of the modules that are part of the current build.
If a module dependency can only be resolved because it has been installed into Maven's local cache and it is not part of the current build, it will be identified as regular dependency.
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`.
@@ -159,6 +162,9 @@ The following example shows how the default ordering described above can be defi
<into layer="application" />
</application>
<dependencies>
<into layer="application">
<includeModuleDependencies />
</into>
<into layer="snapshot-dependencies">
<include>*:*:*SNAPSHOT</include>
</into>
@@ -187,13 +193,15 @@ Any content not claimed by an earlier block remains available for subsequent blo
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 an 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 SNAPSHOT dependencies for the `snapshot-dependencies` layer.
The subsequent `<into>` will claim anything left (in this case, any dependency that is not a SNAPSHOT) for the `dependencies` layer.
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 (in this case, any dependency that is not a SNAPSHOT) for the `dependencies` layer.
The `<application>` block has similar rules.
First claiming `org/springframework/boot/loader/**` content for the `spring-boot-loader` layer.