An `imagePlatform` option for the Maven and Gradle image-building
goal/task can be used to specify the os/architecture of any
builder, run, and buildpack images that are pulled during image
building.
Closes gh-40944
The use of method references requires the referenced method to be
present even if it isn't called. This made it impossible for Gradle
to remove the deprecated methods as it would break our plugin.
By switching the lambdas, the methods only have to be present when
they're called which will only happen with Gradle 8.2 and earlier.
Closes gh-41599
A `trustBuilder` configuration option has been added to the Maven and
Gradle CNB integration image building goal and task. A known set of
builders published by Paketo, Heroku, and Google are trusted by default,
all other builders are untrusted by default.
Closes gh-41352
The model incorrectly marks the Gradle API and all of its
dependencies as test dependencies, making them unavailable in Eclipse
to code in src/main/java. We work around this by modifying the
classpath container to remove the test attribute from the
dependencies that should be available to main code.
See gh-41228
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
Update `anchor-rewrite.properties` to fix a few errors and remove
elements that no longer exist. This commit also fixes a few anchors
in some `.adoc` files.
See gh-40062
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