It now extracts the contents of the JAR in a folder named after the JAR
without the extension. It now also checks if the folder is empty.
There's a new --force option to skip those checks.
The "runner.jar" is now named like the uber JAR from which the
extraction has been started.
See gh-38276
Adds a new jarmode called 'tools'. This provides two commands,
'extract' and 'list-layers'. list-layers is the same as list from
the layertools.
extract is able to extract the JAR in four different modes:
- CDS compatible extraction with libraries in a lib folder and a runner
.jar
- CDS compatible as above, but with layers
- Launcher based
- Launcher based with layers. This is essentially the same as extract
from the layertools
The commands in layertools have been deprecated in favor of the commands
in 'tools'.
This also changes the behavior of layers.enabled from the Gradle and
Maven plugin: before this commit, layers.enabled prevents the inclusion
of the layer index file as well as the layertools JAR.
After this commit, layers.enabled only prevents the inclusion of the
layer index file.
layer.includeLayerTools have been deprecated in favor of includeTools,
and the layertools JAR has been renamed to tools.
Closes gh-38276
Update Gradle and Maven plugins to write an empty `META-INF/BOOT.SF`
file whenever there is a nested signed jar.
This update allows Oracle Java 17 to correctly verify the nested JARs.
The file is required because `JarVerifier` has code roughly equivalent
to:
if (!jarManifestNameChecked && SharedSecrets
.getJavaUtilZipFileAccess().getManifestName(jf, true) == null) {
throw new JarException("The JCE Provider " + jarURL.toString() +
" is not signed.");
}
The `SharedSecrets.getJavaUtilZipFileAccess().getManifestName(jf, true)`
call ends up in `ZipFile.getManifestName(onlyIfSignatureRelatedFiles)`
which is a private method that we cannot override in our `NestedJarFile`
subclass. By writing an empty `.SF` file we ensure that the `Manifest`
is always returned because there are always "signature related files".
Fixes gh-28837
Create alternative launcher classes under the package
`org.springframework.boot.loader.launch` and use them in favor
of the previous location.
This update is designed to improve compatibility with future
changes in the loader.
Closes gh-37667
When building an image using the Maven `spring-boot:build-image` goal or
the Gradle `bootBuildImage` task, the build and launch caches can be
configured to use a bind mount as an alternative to using a named
volume.
Closes gh-28387
A manifest entry `Spring-Boot-Native-Processed: true` is added to the
jar manifest by the Maven or Gradle plugin when the jar has been built
for use in a native image. With the Gradle plugin, this is done in
reaction to the GraalVM Native Image Plugin being applied to the
project. With the Maven plugin, this is done when the `native` profile
is applied to the build.
An `applicationDirectory` option on the Maven
`spring-boot:build-image` goal and the Gradle `bootBuildImage` task
can be configured to set the location that will be used to upload
application contents to the builder image, and will contain the
application contents in the generated image.
Closes gh-34786
A `createdDate` option on the Maven `spring-boot:build-image` goal
and the Gradle `bootBuildImage` task can be used to set the `Created`
metadata field on a generated OCI image to a specified date or to
the current date.
Closes gh-28798
This commit adds a `Build-Jdk-Spec` attribute to the manifest in a
jar or war file built with the Spring Boot Gradle plugin. This
aligns the Gradle plugin's behavior with the default Maven plugin
behavior.
This removes the need to set a `BP_JVM_VERSION` environment variable
when invoking Cloud Native Buildpacks, as the Paketo buildpacks will
honor `Build-Jdk-Spec` in a jar or war manifest to determine the
default JVM version.
Fixes gh-32829
