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
Rather than using the extension directly, introduced a dedicated
annotation will enable customization of the compatibility tests that
are run via attributes on the annotation. For example, it will allow
certain test classes to run their tests with Gradle's configuration
cache enabled while others disable it.
Closes gh-23532
Previously, BootJar would resolves all of a project's configurations
when building a layered jar. This was unnecessarily broad as it was
likely to include configurations that had contributed nothing to the
jar's classpath.
This commit replaces the configuration resolution with an afterResolve
action that populates the ResolvedDependencies in response to a
configuration being resolved. This allows the resolved dependencies to
be populated from all of the configurations that were resolved as part
of determining the jars classpath and no more.
Closes gh-23528
Prior to this commit, the bootBuildInfo was configured eagerly.
Configuring it lazily prevent this task from being configured when not
explicitly needed. Also, the 'classes' and 'bootJar' tasks are now
lazily configured, as the bootBuildInfo task was causing them to be
configured eagerly.
See gh-23435
This commit adds the ability to configure the Maven and Gradle
plugins to use a remote Docker daemon using build file
configuration, as an alternative to setting environment variables
to specify remote host connection details.
Fixes gh-23400
This commit adds the ability to configure Docker image registry
authentication credentials in the Maven and Gradle plugins. The
authentication credentials are passed to the Docker daemon with
all daemon API calls, and the daemon forwards the credentials to the
image registry when necessary. This makes it possible to use
builder and run images stored in a private Docker registry.
See gh-22972
This commit updates the Gradle Plugin to filter dependencies based on
the Spring-Boot-Jar-Type entry in their manifest. Jars with a
Spring-Boot-Jar-Type of dependencies-starter are excluded. Unlike the
Maven plugin, jars with a type of annotation-processor are not
excluded. It is not necessary with Gradle as use of the
annotationProcessor configuration for such dependencies already ensures
that they are not included.
See gh-22036
This commit adds a pullPolicy option to the configuration of the Maven
plugin spring-boot:build-image goal and the Gradle plugin bootBuildImage
task. The new option gives users control over pulling the builder image
and run image from a remote image registry to the local Docker daemon.
See gh-22736
This commit adds a check to the support code for the Gradle plugin
bootBuildImage task to ensure that the jar file that will be passed
to a builder is readable and has a valid directory. This prevents a
situation where the jar file cannot be read because it is prepended
with a launch script, and the builder does not receive any files to
process.
Notes have also been added to the Gradle plugin documentation to warn
against using a bootJar launchScript configuration and bootBuildImage
together, as well as caveats about launchScript that match the Maven
plugin documentation.
Fixes gh-22223
Prior to this commit, an image name or run image name derived from
the project name or provided by the user would be passed to the CNB
builder without validation by the Maven plugin build-image goal or
Gradle plugin bootBuildImage task. This could lead to error messages
from the plugins that are difficult to understand and diagnose.
This commit makes parsing of the image names more strict, based on
the grammar implemented by the Docker go library. This provides
validation of the image names before passing them to the builder,
with a more descriptive error message when parsing and validation
fails.
Fixes gh-21495
Previously, Spring Boot's modules published Gradle Module Metadata
(GMM) the declared a platform dependency on spring-boot-dependencies.
This provided versions for each module's own dependencies but also had
they unwanted side-effect of pulling in spring-boot-dependencies
constraints which would influence the version of other dependencies
declared in the same configuration. This was undesirable as users
should be able to opt in to this level of dependency management, either
by using the dependency management plugin or by using Gradle's built-in
support via a platform dependency on spring-boot-dependencies.
This commit reworks how Spring Boot's build uses
spring-boot-dependencies and spring-boot-parent to provide its own
dependency management. Configurations that aren't seen by consumers are
configured to extend a dependencyManagement configuration that has an
enforced platform dependency on spring-boot-parent. This enforces
spring-boot-parent's version constraints on Spring Boot's build without
making them visible to consumers. To ensure that the versions that
Spring Boot has been built against are visible to consumers, the
Maven publication that produces pom files and GMM for the published
modules is configured to use the resolved versions from the module's
runtime classpath.
Fixes gh-21911
This commit adds a runImage property to the Maven plugin build-image
goal and the Gradle bootBuildImage task. The property allows the user
to override the run image reference provided in the builder metadata
with an alternate run image. The runImage property can be specified
in the build file or on the command line.
Fixes gh-21534
Previously, the productionRuntimeClasspath configuration was created
without any attributes. This caused problems with multi-project
dependency resolution as there was insufficient information for Gradle
to determine which variant of a dependency should be used by the
productionRuntimeClasspath configuration.
This commit updates the configuration to have three attributes, each
configured with the same values as those of Gradle's own
runtimeClasspathConfiguration.
Fixes gh-21549
Prior to this commit, the published Maven POMs would not pass the Maven
Central mandatory checks.
This commit adds the missing project name and description metadata for
most artifacts. The Spring Boot Gradle plugin artifact was also missing
this information and this is now added in the plugin metadata itself.
This is also updating the project page URL which is now hosted directly
on spring.io.
Fixes gh-21457
Prior to this commit, the build tool plugins set the environment
variable BP_JAVA_VERSION when invoking the CNB builder to set the
version of the JDK/JRE that the builder should use in the created
image.
With CNB API 0.3, the convention changed the name of this environment
variable to BP_JVM_VERSION. This commit updates the build tool
plugins to match the newer convention.
See gh-21273
This commit modifies the buildpack platform invocation logic used by
the build plugins to invoke the single creator lifecycle introduced in
the CNB API 0.3, instead of invoking discrete lifecycle phases
separately. It also removes support for CNB API 0.2.
Fixes gh-21273
The warnings will be addressed by gh-20759. CreateBootStartScripts
must be excluded from the classes that are validated by the
ValidatePlugins task. It is invalid, but only for Gradle 6.4. gh-20759
will cause it to only be used with Gradle 6.3 and earlier.
See gh-21329
This commit changes the default builder image from
`cloudfoundry/cnb:bionic-platform-api-0.2` to
`gcr.io/paketo-buildpacks/builder:base-platform-api-0.3`. It also
uses a `paketo-buildpacks/builder` image instead of a
`cloudfoundry/cnb` image to test compatibility with lifecycle v2
and uses paketo naming instead of cloudfoundry when mocking builder
interactions.
Some adjustments to lifecycle phases were also made to align more
closely with the pack CLI.
Fixes gh-21066
Previously, the developmentOnly configuration, typically used for
Devtools, had to be declared manually. The BootJar and BootWar tasks
then had a property, excludeDevtools, that could be used to control
whether or not Devtools would be excluded from the executable archive.
This commit updates the reaction to the Java plugin being applied to
automatically create the developmentOnly configuration. The classpaths
of bootJar and bootWar are then configured not to include the contents
of the developmentOnly configuration. As a result of this, the
excludeDevtools property is no longer needed and has been deprecated.
Its default has also been changed from true to false to make it easy
to opt in to Devtools, when configured as a development-only
dependency, being included in executable jars and wars by adding
developmentOnly to the classpath of the archive task.
Closes gh-16599
This commit removes changes the timestamp used when writing the
classpath and layers index files in the Gradle plugin to be the
current timestamp unless `preserveFileTimestamps=true`. It also
polishes some duplication in the handling of entry attributes
when creating the fat archive and adds a test to verify that
the Gradle plugin uses the same fixed timestamp constant as
Gradle uses internally.
See gh-21005
This commit ensures that file permissions are set on entries that the
Gradle plugin adds to an archive. It also reverts the constant date
and time used for added entries to a previous value to ensure a time
zone offset is not applied.
See gh-20927
This commit adds examples for configuring the default builder to use
an HTTP/HTTPS proxy when building OCI images using the Maven or Gradle
plugin.
Fixes gh-19984
Update the Gralde plugin so that layered jars now use the regular "flat"
format. The layers.idx file now describes which layer each file should
be placed.
See gh-20813
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Create a dedicated layer that is used to hold the launcher support
classes. The layer sits between `dependencies` and
`snapshot-dependencies` so that the layer is sensible for both
SNAPSHOT and RELEASE versions of Spring Boot
Closes gh-20529
Simplify layer customization logic for both Maven and Gradle and
refactor some internals of the Gradle plugin.
Both Maven and Gradle now use a simpler customization format that
consists of `application`, `dependencies` and `layer order` sections.
The `application`, `dependencies` configurations support one or more
`into` blocks that are used to select content for a specific layer.
Closes gh-20526
This commit adds support for Cloud Native Buildpacks builder platform
API 0.3, which is the latest platform API available currently. Support
for platform API 0.1 has been removed, adopting the policy of the pack
CLI to support the current platform API version and one version prior.
Fixes gh-20757
CNB builder images are now being tagged in a manner that indicates
the version of the platform API implemented. This allows Spring Boot
to default to a builder tag that guarantees API compatibility while
allowing for updates to bundled buildpacks.
Fixes gh-20171
This commit adds documentation for the configuration required to
use a remote Docker daemon with the `build-image` Maven goal or the
`bootBuildImage` Gradle task.
See gh-20538
This commit adds support for setting the image name and builder
parameters of the Gradle bootBuildImage task using command-line
options as an alternative to DSL configuration.
See gh-20520
This commit adds configuration to the Spring Boot Gradle plugin that
allows the names and contents of layers to be customized in the build
configuration.
Fixes gh-20296
With this commit, the Maven `spring-boot:build-image` goal and the
Gradle `bootBuildImage` task will configure the OpenJDK buildpack
to use the same JRE version as the project's target version,
provided the buildpack Java version is not explicitly set in the
build configuration.
Fixes gh-20172
This commit adds a `createdBy` structure to the metadata of the ephemeral
builder container image that identifies Spring Boot as the creator of the
image, along with the Spring Boot version.
See gh-20126
This commit upgrades the default CNB builder image from
cloudfoundry/cnb:0.0.43-bionic to cloudfoundry/cnb:0.0.53-bionic.
It also adds integration tests for the Maven and Gradle plugins
to verify both versions are supported.
Stephane Nicoll
izeye
Andy Wilkinson
dreis2211
Scott Frederick
Phillip Webb
jnizet
Stefan Wolf
Scott Frederick
Robert Smith
Madhura Bhave
jongmin92
Stephane Nicoll
olivier.antoine
Andy Wilkinson
Emily Casey
Lukas Cardot
Sebastiaan Fernandez
姜为
EruDev
Martin Chalupa
anshlykov
Dave Syer
Brian Clozel
Phillip Webb
Paddy Drury