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.