Replace `DockerImageNames` with a enum and relocate it from the
`testcontainers` to `container` package. The enum now also
becomes a common location that we can use to apply container
configuration such as timeouts.
Closes gh-41164
Co-authored-by: Phillip Webb <phil.webb@broadcom.com>
The test CNB builder and buildpack used in integration tests have moved
from a projects.registry.vmware.com registry to ghcr.io/spring-io. This
commit modifies tests to use the new location.
Closes gh-40800
When the `buildWorkspace` location in the
`spring-boot:build-image` Maven goal or `bootBuildImage` Gradle
task is configured to use a local bind source, the location
is passed to the CNB lifecycle without further processing by
Spring Boot. The lifecycle is in control of creating any files
in the specified location. Spring Boot tries to remove the
directories at the specified location after an image is
successfully created, but should not fail the image build
if the lifecycle has created files or directories with
permissions that keep them from being deleted successfully.
Fixes gh-40760
In order to support Java 22, we must use spring-core 6.1.x.
spring-core 6.1.x is a multi-release jar so, in order to support Java
22, a version of Gradle that supports multi-release jars must be
used.
This commit adds a new variant to spring-boot-gradle-plugin for
modern versions of Gradle. When Gradle's plugin API version is 8.7 or
later, we use spring-core 6.1.x. spring-core 6.0.x is used at all
other times.
Closes gh-40074
1. remove unused imports
2. remove redundant semicolon
3. remove empty class body
4. remove redundant 'constructor' keyword
5. remove redundant 'Unit' return type
6. use non-null type if possible
See gh-38708
Add a `NestedFileSystemProvider` implementation so that the JDK's
`ZipFileSystem` can load content from nested jars and nested
directory entries.
Creating a `ZipFileSystem` may be a relatively expensive operation as
zip structures need to be parsed and in the case of directory entries
a virtual datablock nees to be generated on the fly. As such, we
install the `ZipFileSystem` as late as possible since in a typical
application it may never be needed.
This commit also tweaks Gradle and Maven plugins to ensure that the
service loader file is written to repackaged jars.
Closes gh-7161
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
Rewrite nested jar code to better align with the implementations
provided in Java 17. This update makes two fundamental changes to
the previous implementation:
- Resource cleanup is now handled using the `java.lang.ref.Cleaner`
- Jar URLs now use the form `jar:nested:/my.jar/!nested.jar!/entry`
Unlike the previous `jar:jar:/my,jar!/nested.jar!/entry` URL format,
the new format is compatible with Java's default Jar URL handler.
Specifically, it now only uses a single `jar:` prefix and it no longer
includes multiple `!/` separators.
In addition to the changes above, many of the ancillary classes have
also been refactored and updated to create cleaner APIs.
Closes gh-37668