Previously, the targetJavaVersion property of bootBuildImage was set
using the project's target compatibility directly. This meant that
property's value would reflect the configured target compatibility at
the time of the task's creation and any subsequent changes to the
target compatibility would be missed.
This commit updates the registration of the bootBuildImage task to set
the value of the targetJavaVersion property using a provider. This
indirection means that the project's target compatibility isn't read
until the value of the targetJavaVersion is read, allowing any changes
to the target compatibility to be picked up even if they're made after
the bootBuildImage task has been created.
Fixes gh-26297
This commit modifies the integration tests for the Maven and Gradle
image building goal and task to use a custom builder as a test harness
to verify that the plugins invoke the builder as expected.
Fixes gh-25838
This commit corrects the order.toml file that is generated and added
to the builder when building an image using custom buildpacks with the
Maven or Gradle plugin in order to support buildpacks that depend on
detection as a group.
Fixes gh-25378
This commit adds configuration to the Maven and Gradle plugins to
allow a list of volume mount bindings to be provided to the image
building goal and task. This enables service bindings to be mounted
in the builder image that are recognized by buildpacks to support
custom certificates, build tool configuration, APM integration, and
other buildpack features.
Fixes gh-23518
This commit adds configuration to the Maven and Gradle plugins to
allow a list of buildpacks to be provided to the image building
goal and task.
Fixes gh-21722
Previously, when building a layered jar, the Gradle plugin only
considered a configuration's direct dependencies when identifying
project dependencies. This resulted in transitive project dependencies
being missed when deciding which dependencies belong in the
application layer.
This commit updates ResolvedDependencies to consider all projects
from the root project when collecting the IDs of local projects. This
ensures that any project dependency, no matter where it appears in the
dependency graph, is successfully identified.
Fixes gh-25163
Update `build.gradle` files to ensure that `junit-platform-launcher` is
a `testRuntimeOnly` dependency. This ensures that tests can be run from
Eclipse.
Closes gh-25074
Previously, unlike the application plugin's run task, our bootRun task
ignored the project's Java toolchain. This meant that the application
was run on a JVM with the same Java version as the one being used by
Gradle itself. This could result in a failure if the application
required a more modern JVM.
This commit updates the plugin to configure the bootRun task's
JavaLauncher convention to be one derived from the project's Java
toolchain. Toolchain support was introduced in Gradle 6.7 so this is
only done when using Gradle 6.7 and later.
Fixes gh-24517
Previously, bootRun assumed that the Java version of the JVM that would
run the application would be the same as the Java version of the JVM
that is running the build. This assumption does not hold true when
Gradle's toolchain support is used to configure tasks that fork a new
JVM to use a version other than that being used by Gradle itself.
This commit updates the BootRun task to query the JavaLauncher property
when determining the version of Java on which the application will be
run. Toolchain support and the JavaLauncher property are new in Gradle
6.7. To support earlier versions of Gradle, NoSuchMethodError is caught
we continue as if no JavaLauncher has been configured and use the local
JVM's Java version.
Fixes gh-24512
Prior to this commit, running the bootBuildImage Gradle task on a
project configured for war packaging would result in a jar file being
built and used in the image instead of the war file. With this commit
an error will be thrown from the plugin in this case.
Fixes gh-24521
This commit sets the pull policy to `IF_NOT_PRESENT` where possible
in integration tests for the Maven and Gradle plugins to reduce
the number of times the default Paketo builder and run images are
pulled from Docker Hub.
Fixes gh-24113
When a Configuration is copied, any before and after resolve actions
that are registered with its ResolvableDependencies are also copied
over. This means that, when a copied configuration is resolved the
resolution actions may be called on a ResolvableDependencies instances
that isn't the one to which they were added.
Previously, the above-described Gradle behaviour would result in
BootJar accessed the ResolvedConfiguration of a Configuration that may
not have yet been resolved. At best this would trigger Configuration
resolution and at worst it would fail. A failure could occur if the
configuration had been copied so that it could be made resolvable.
The afterResolve action would then try to access the
ResolvedConfiguration of the original Configuration. This would trigger
a resolution attempt that fails due to the original configuration being
marked as unresolvable.
This commit updates the afterResolve action in BootJar to check that
the ResolvableDependencies with which it is called matches the
ResolvableDependencies with which it was original registered. Only
when the two match, and therefore the configuration has actually been
resolved, does processing proceed.
Fixes gh-24072
Previously, when building a layered jar with Gradle, project
dependencies 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 Gradle to include
project dependencies in the application layer by default. The DSL has
also been updated to allow their layer to be customized using new
includeProjectDependencies() and excludeProjectDependencies() methods
rather than relying on including and excluding them via a
group:artifact:version pattern.
Closes gh-23431
This commit updates the default builder image used by the Maven
and Gradle plugins image-building goal and task to use the latest
Paketo builder image. The builder image is pulled from Docker Hub
instead of Google Container Registry by default.
See gh-23628
This commit qualifies examples of configuring the CNB builder to clarify
that the examples apply to use of the default Paketo builder, and adds links
to the official Paketo docs for more details.
Fixes gh-19967
A docker registry running in testcontainers behaves
differently in CI vs running locally. Disabling the tests for
now while working on getting them running reliably in CI.
See gh-21001
This commit adds options to the Maven and Gradle plugins to publish
to a Docker registry the image generated by the image-building goal
and task.
The Docker registry auth configuration added in an earlier commit
was modified to accept separate auth configs for the builder/run
image and the generated image, since it is likely these images will
be stored in separate registries or repositories with distinct
auth required for each.
Fixes gh-21001
Andy Wilkinson
Stephane Nicoll
izeye
dreis2211
Scott Frederick
Phillip Webb
jnizet
Stefan Wolf
Scott Frederick
Robert Smith
Madhura Bhave
jongmin92
Stephane Nicoll
olivier.antoine
Andy Wilkinson
Emily Casey