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
Prior to this commit, the build plugin goal/task for building images
required a locally running Docker daemon that was accessed via a
non-networked socket or pipe.
This commit adds support for remote Docker daemons at a location
specified by the environment variable `DOCKER_HOST`. Additional
environment variables `DOCKER_TLS_VERIFY` and `DOCKER_CERT_PATH`
are recognized for configuring a secure TLS connection to the daemon.
Fixes gh-20538
This commit provides a versioned xsd for the layers configuration of the
Maven plugin. The version starts at `2.3` to match with the Spring Boot
feature release in which this was introduced.
Closes gh-20663
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 enables javadoc generator for the Spring Boot Maven plugin.
This also harmonizes the structure of the documentation, with an `/api`
and a `/reference` root directories for the javadoc and the reference
guide respectively.
Closes gh-20127
This commit adds support for setting the image name and builder
parameters of the Maven spring-boot:build-image goal using command-line
properties as an alternative to plugin configuration in pom.xml. Per
Maven conventions, a value in pom.xml configuration will override a
command-line property when both are provided.
Fixes 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
Maven's war plugin does not support reproducible builds, resulting in
the entries in the war file not being written in a consistent order
from build to build.
Closes gh-20176
This commit adds an additional 'layers/configuration' property that can
be used to refer to a separate layers configuration file. This separate
file defines:
* The layers and their order of precedence,
* How libraries are handled using filters that match against the
coordinates of each library, and
* How classes are handled using filters that match against the location
of the entry
An XSD to validate the XML configuration file is available.
Closes gh-20295
Co-authored-by: Stephane Nicoll <snicoll@pivotal.io>
This commit fixes problems with file path separators and command
line argument quoting in Maven plug integration tests when run on
Windows.
Fixes gh-20244
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 changes the order of precedence for the `arguments` property
of the AbstractRunMojo so that values specified in the POM override
values provided on the command line using `spring-boot.run.arguments`.
This brings the `arguments` property in line with all other Mojo
parameters.
Fixes gh-20024
This commit fixes the `Created` date and time of the ephemeral builder
container image at the Windows epoch plus one second
(1980-01-01T00:00:01Z). This date matches the created date of the builder
image and influences the created date of the resulting image. Using
a fixed date for images ensures that the digest is consistent for all
images with the same version.
Fixes gh-20126
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.
Cloud Native Buildpacks platform API version 0.2 introduced
two breaking changes: the order of invoking the restore and analyze
phases was reversed, and the cache phase was removed in favor of
distributing caching across other phases.
This commit adds support for Cloud Native Buildpacks builders that
implement platform API version 0.2, while maintaining compatibility
with builders that implement Lifecycle version platform API
version 0.1.
Closes gh-19829
This commit registers 'org.springframework.boot.deployed' to
spring-boot-configuration-metadata and spring-boot-properties-migrator
to make sure they are deployed as expected.
See gh-20051
Previously, the image builder used by the build tool plugins ignored
errors from lifecycle phases and continued with subsequent phases.
This commit inspects the status of the builder container after each
lifecycle phase and aborts the image building process if the exit
status of the container after any phase is non-zero.
Fixes#19949
This documentation moves the specific `build-image` execution
configuration example of the Maven plugin documentation to the general
plugin configuration. This makes sure that it works in most cases and
an execution-specific configuration is not required here anyway.
Closes gh-19946
With the introduction of Gradle we lost the list of version properties
that were previously in the spring-boot-dependencies POM and were also
linked inside the documentation. This commit introduces an appendix
section in the docs and links the appropriate places to the new section
to restore discoverability.
See gh-19898
Previously \r\n was used on Windows and \n was used on other
platforms. This resulted in different JSON content being written to
the archive. As the config's entry name is the SHA-256 hash of its
content, it also resulted in the entry name being different.
This commit updates the JSON that's written into the archive to use
\n line endings, irrespective of the OS on which the image is being
built.
See gh-19828
We build with Java 8, 11, and 13 without specifying target
compatibility for the bytecode of the app that's placed in the image.
The built image uses Java 11 and when the app is built with Java 13
it fails to start as the Java 11 VM can't read that Java 13 bytecode.
This commit configures the app that's placed in the image to be built
with target compatibility of 1.8. This allows it to be compiled with
all version of Java with which we build and to also be compatible
with the JVM that's in the image.
See gh-19831
This commit changes uses of ClassLoader.loadClass to Class.forName for
consistency with what was initiated in #19342 and better compatibility
with GraalVM.
Closes gh-19824
Update `LaunchedURLClassLoader` to ensure that the `JarModeLauncher`
is created in the correct classloader.
Prior to this commit the launcher was created by the application
classloader and did not have access to any of the required
`org.springframework` classes.
See gh-19848
Update all dependencies declarations to use the form `scope(reference)`
rather than `scope reference`.
Prior to this commit we declared dependencies without parentheses unless
we were forced to add them due to an `exclude`.
Replace Gradle single quote strings with the double quote form
whenever possible. The change helps to being consistency to the
dependencies section where mostly single quotes were used, but
occasionally double quotes were required due to `${}` references.
Fix a bug in `ExplodedURLClassLoader` and merge the code into the
existing `LaunchedURLClassLoader` class. Also polish a few method
names relating to layer support.
See gh-19848
See gh-19767
Rename the `spring-boot-cloudnativebuildpack` module to
`spring-boot-buildpack-platform` and update the the package
name to `org.springframework.boot.buildpack.platform`.
Closes gh-19851
Add a new `spring-boot-layertools` module which provides jarmode support
for working with layers. The module works with both classic fat jars,
as well as layered jars.
Closes gh-19849
Update the `Launcher` class to allow a packaged jar to be launched in
a different mode. The launcher now checks for a `jarmode` property and
attempts to find a `JarMode` implementation using the standard
`spring.factories` mechanism.
Closes gh-19848
Previously, the generated resources were added as an output to the
main source set. This worked on the command line, but resulted in
the META-INF folder that contains the loader jar not being on the
classpath of downstream projects in Eclipse.
This commit changes loader-tools to add the generated resources
as a srcDir to the main source set. This results in it appearing on
the classpath of other projects in Eclipse that depend on loader-tools
such as the Gradle plugin, thereby allowing its tests to be run in
the IDE as well as on the command line.
Fixes gh-19841
Pull functionality from `Repackager` into a new `Packager` base class
and develop a variant for Docker image creation. The new `ImagePackager`
class provides a general purpose way to construct jar entries without
being tied to an actual file. This will allow us to link it to a
buildpack and provide application content directly.
Closes gh-19834
Add a Java implementation of the buildpacks.io specification allowing
projects to be packaged into OCI containers. The `builder` class
provides a Java equivalent of `pack build` command and is based on
the `pack` CLI Go code published at https://github.com/buildpacks/pack.
Closes gh-19828
Support an alternative fat jar format that is more amenable to Docker
image layers.
The new format arranges files in the following structure:
BOOT-INF/
layers/
<layer-name #1>
/classes
/lib
<layer-name #2>
/classes
/lib
The `BOOT-INF/layers.idx` file provides the names of the layers and the
order in which they should be added (starting with the least changed).
The `JarLauncher` class can load layered jars in both fat and exploded
forms.
Closes gh-19767
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Update the `Repackager` class so that an additional `classpath.idx` file
is written into the jar that provides the original order of the
classpath. The `JarLauncher` class now uses this file when running as
an exploded archive to ensure that the classpath order is the same as
when running from the far jar.
Closes gh-9128
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
The JarFile was not being closed which linked a file handle and caused
a test failure on Windows.
The local variable has been renamed as, when declared in a
try-with-resources, Checkstyle was confused by the shadowing of the
jarFile field and required references to jarFile within the try-block
the be prefixed with this.
See gh-19595
This paves the way for publishing Gradle module metadata once the
problem caused by snapshot versions and our two-step publication
process has been addressed.
See gh-19609
This reverts commit b34a311d02 as,
having disabled the publishing of Gradle's module metadata (4f75ab5),
the changes are no longer needed.
See gh-19609
Previously, enforcedPlatform dependencies were using to pull in the
constraints defined in spring-boot-dependencies and
spring-boot-parent and applied them strictly so that the constrained
version had to be used. This worked as intended in Spring Boot's own
build but incorrectly enforced those same strict version requirements
on external consumers of Spring Boot's modules.
This commit reworks how Spring Boot defines its internal dependency
management so that platform dependencies are exposed to external
consumers while enforced platform dependencies are using internally.
See gh-19609
Enforcing the spring-boot-dependencies platform makes for too strong
an opinion about the version of Kotlin that should be on the build
script's classpath. It clashes with the version of Kotlin that's
embedded in Gradle and used with Gradle's Kotlin DSL.
This commit switches to a normal platform (rather than an enforced
platform) which allows it to express an opinion about the version of
Kotlin without making it a strict requirement.
Closes gh-19609
Phillip Webb
Andy Wilkinson
Scott Frederick
dreis2211
Madhura Bhave
Stephane Nicoll
Johnny Lim
Mike Smithson
zhangt2333
Dmytro Nosan
Brian Clozel