Previously, when writing a repackaged jar, an attempt to write all of
an entry's parent directories would always be made, irrespective of
whether or not the entry itself had already been written. This was
inefficient as, due to the way that the jar is written, once an entry
itself has been written, we know that all of its parent directories
will also have been written.
This commit updates the jar writer so that no attempt is made to
write parent directory entries if the entry itself has already been
written.
Fixes gh-29175
Update the Maven and Gradle packaging for war files so that a
`classpath.idx` file is written into the archive that provides the
original order of the classpath, as was previously done for jar files.
The `WarLauncher` class will use this file when running as an exploded
archive to ensure that the classpath order is the same as when running
from the far war.
Fixes gh-19875
This commit adds configuration to the Maven and Gradle plugins to
allow specifying the names of build and launch cache volumes provided
to the CNB builder.
See gh-28292
Update `JarURLConnection` to use a single shared wrapper per
jar file rather than creating a new one each time. This update
should help to reduce GC pressure.
Fixes gh-28042
Update Maven and Gradle plugins to allow build info properties to be
excluded.
Prior to this commit, the `BuildPropertiesWriter` would fail with an
NPE if the group, artifact, name or version properties were `null`.
This was specifically problematic with the Gradle plugin, since its
DSL allows `null` properties which would either be passed to the writer
or, in the case of `artifact`, converted into a string value of
"unspecified".
See gh-27412
This commit adds configuration to the Maven and Gradle plugins to
allow specifying multiple tag to be created that refer to the built
image.
See gh-27613
Adding a label to the ephemeral builder image cloned from the base
builder image eliminates contention between builds that are run
concurrently. Without this label, concurrent builds could result in
a race condition in the Docker daemon if the ephemeral builder image
shared by builds was deleted by both builds at exactly the same time.
Fixes gh-27888
Previously, the optional configuration was added to the compile and
runtime classpaths of each source set and the the javadoc classpath
as well. This had a few disadvantages, the most notable of which is
that it meant that the configuration was ifrst resolved and then
the outcome of the resolution was added to the compile and runtime
classpaths. As a result, none of the attributes on the compile and
runtime classpaths were considered to influence variant selection.
This commit reworks the optional dependencies plugin so that the
compile and runtime classpaths of each source set are now configured
to extend from the optional configuration. This allows each
classpath configuration's attributes to influence the dependencies
that are selected from the optional configuration during resolution.
For example, when resolving the compile classpath, compile
dependencies (Usage.JAVA_API) will be selected and when resolving the
runtime classpath, runtime dependencies (Usage.JAVA_RUNTIME) will be
selected.
The above-described change means that runtime dependencies of an
optional dependencies will no longer leak into the compile classpath.
As a result of this, our Gradle plugin's test infrastructure has
been updated so that it no longer references runtime dependencies of
the Kotlin Gradle plugin at compile time.
Closes gh-27965
Previously, a Zip64 jar file was identified by the number of entries
in the central directory being 0xFFFF. This value indicates that
there the number of entries is too big for the 2-byte field. However,
a jar may be in Zip64 format due to it exceeding the Zip format's
maximum size rather than its maximum number of entries so this field
cannot be used as a reliable indicator. The Zip specification doesn't
require any of the fields of the end of central directory record to
have a value of 0xFFFF (2-byte fields) or 0xFFFFFFFF (4-byte fields)
when using Zip64 format so we need to take a different approach.
Additionally, a number of places in the code assumed that an entry's
offset would always be available from the central directory file
header directly. This assumption did not hold true when the jar was
a Zip64 archive due to its size as the offset's value would be
0xFFFFFFF indicating that it should be read from the Zip64 extended
information field within the header's extra field instead.
This commit updates the Zip64 detection to look for the Zip64 end of
central directory locator instead. If present, it begins 20 bytes
before the beginning of the end of central directory record. Its
first four bytes are always 0x07064b50. The code that reads the
local header offset has also been updated to refer to the Zip64
extended information field when the offset is too large to fit in
the 4-byte field in the central directory file header. To allow
greater-than-4-byte offsets to be handled, a number of fields,
method parameters, and local variables have had their type changed
from an int to a long.
Fixes gh-27822
When a Maven build is configured to ensure reproducibility, any
libraries added to `BOOT-INF/lib` in a jar archive or to `WEB-INF/lib`
in a war archive by the Spring Boot plugin repackaging should be
sorted by name to ensure a stable and predictable order.
Fixes gh-27436
This commit adds configuration to the Maven and Gradle plugins to
allow specifying the network mode to be provided to the image
building goal and task.
See gh-27486
An exception being thrown while the Maven plugin is uploading the app
archive bits to an ephemeral builder container would leave the
interaction with the Docker daemon in a state that caused further
interaction with the daemon (such as deleting the ephemeral builder)
to hang indefinitely. This commit cleans up the connection on an
exception to prevent this condition.
Fixes gh-27515
An upgrade to Apache Commons Compress allows the build plugins to write
the launch script to the fat jar as a proper preamble, making the file
compatible with more jar and zip tooling.
Fixes gh-22336
A new system test plugin is being made available for running test
suites that should be run less frequently than with every commit, such
as tests that verify Spring Boot compatibility with external
projects. CI pipeline configuration for running system tests is also
provided.
The first system tests verify the behavior of the Spring Boot image
building plugins when building images using Paketo buildpacks.
Closes gh-25824
Update `RepackageMojo` and supporting classes so that `exclusions`
on the repackage goal apply to both the contributed libraries and any
existing jar entries already contained in the original war.
Prior to this commit, exclusions would apply to contributed jars (for
example, those in `WEB-INF/lib-provided`) but not jars that were
packaged directly into `WEB-INF/lib` by the war plugin
Fixes gh-15808
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Previously, a project with a dependency on Spring Boot's configuration
processor would fail to build when the configuration cache is enabled
due to it accessing the Project during task execution.
Instead of accessing the project during task execution, this commit
updates the code to retrieve the resource locations from the matching
source set in advance. The locations are then stored in the action
that configures the compile task when needed.
Closes gh-26880
Using the revision line means that the revision number is automatically
set. The revision number is then included by the HTML and PDF backends
in the standard location. In the HTML backend that's alongside the
list of authors. In the PDF backend that's on the title page.
Closes gh-26851
In our tests, the JNI code in Netty tcNative can cause some of its
classes to be loaded using a ModifiedClassPathClassLoader. When the
wrong class loader is used, SSL-related tests fail, for example due
to the same Netty tcNative classes being loaded by two different
ClassLoders and no longer being the same. This appears to be
dependent upon the order in which tests are executed and results in
intermittent test failures.
It looks like this should be addressed in Netty tcNative 2.0.40 which
preloads all of its classes. In the meantime, this commit updates
ModifiedClassPathClassLodaer to ignore Netty tcNative classes so that
they're only ever loaded by the system class loader.
Closes gh-26749
7.1-rc-1 deprecates JavaExec's main property in favor of mainClass
which was introduced in Gradle 6.4. This commit updates some tests
to use mainClass rather than main that would otherwise have failed
due to deprecation warnings in their output.
Closes gh-26793
Update `JarFile` and `JarFileWrapper` classes so that they no longer
close the `JarFile` early if a `SecurityManager` is in use.
Prior to this commit, the closed `JarFile` would cause (an ultimately
swallowed) NPE in `ZipFile` which manifested itself as a
`ClassNotFoundException` when starting the app.
Closes gh-25538
When a custom buildpack is provided for image building, the contents
of the buildpack directory, tgz file, or image are copied as tar
entries to a new layer in the ephemeral builder image. Prior to this
commit, only file entries from the buildpack source were copied as
builder layer tar entries; intermediate directory entries from the
source were not copied. This results in directories being created in
the builder container using default permissions. This worked on most
Linux-like OSs where the default permissions allow others-read
access. On some OSs like Arch Linux where the default directory
permissions do not allow others-read, this prevented the lifecycle
processes from reading the buildpack files.
This commit explicitly creates all intermediate directory tar entries
in the builder image layer to ensure that the buildpack directories
and files can be read by the lifecycle processes.
Fixes gh-26658
Update `ImageName` and `ImageReference` to use distinct regex patterns
to parse specific parts of the value. Prior to this commit a single
regex pattern was used which could hang given certain input strings.
Fixes gh-23115
Change `SpringBootPlugin.PRODUCTION_RUNTIME_CLASSPATH_NAME` from package
private to public so that it can be accessed in user build scripts.
Fixes gh-26686
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 changes the Maven build-image goal to honor the `layout` and
`layoutFactory` parameters to ensure that the archive content sent to the
builder is the same as is used by the `repackage` goal to build the
archive file.
Fixes gh-26216
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 disables a test that does not test what it is supposed to
and improve the Metadata assertions to fail early if more than one
matching item by name and type is found in the metadata.
See gh-26271
Update `MavenPublishingConventions` to add a new `mavenOptional` feature
that allows us to declare optional dependencies that are also published
in the generated POM.
This change allows us to include the maven-shade-plugin in the
spring-boot-maven-plugin POM which fixes an issue with Eclipse m2e.
Fixes gh-21992
This commit copies the file mode along with other attributes when
copying files from the source archive to the build container while
building an image using the Gradle plugin. This preserves file
permissions on any resources included in the source archive.
Fixes gh-25915
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
Previously, the configuration metadata annotation processor only
declared support for `@Endpoint` and none of the other more
specialized `@…Endpoint` annotations that are meta-annotated with
`@Endpoint` such as `@WebEndpoint` and `@JmxEndpoint. This would
result in missing metadata if a full or incremental build only
compiled classes annotated with one of the more specialized
`@…Endpoint` annotations as the annotation processor would not be
called.
This commit updates the processor's supported annotation types to
include every known `@…Endpoint` annotation. The test processor has
also been similarly updated to align its behaviour with that of the
main processor.
Fixes gh-25388
When the `finalName` parameter is incorrectly set in the Spring Boot
Maven plugin configuration instead of in the `build` configuration, the
repackaged and original archive files are not named as expected. Prior
to this commit, the image building goal would detect this error
condition and throw an exception late in the process of creating the
build container, leaving the container in an unstable state. This
commit changes the image building goal to detect this condition early,
before attempting to create the container.
Fixes gh-25590
When the `finalName` parameter is incorrectly set in the Spring Boot
Maven plugin configuration instead of in the `build` configuration, the
repackaged and original archive files are not named as expected. Prior
to this commit, the image building goal would detect this error
condition and throw an exception late in the process of creating the
build container, leaving the container in an unstable state. This
commit changes the image building goal to detect this condition early,
before attempting to create the container.
Fixes gh-25590
This commit improves SimpleConfigurationMetadataRepository to include
properties that are contributed to an existing configuration metadata
source.
See gh-25507
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, when an authenticated Docker builder registry was
configured in the Maven or Gradle plugin and the builder and run
images specified different registries, the authentication credentials
would be sent to both registries. This could cause confusion if both
registries don't recognize the same credentials. This commit enforces
that both images are in the same registry when authentication
is configured.
Fixes gh-24552
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
This commit removes the `layout` and `layoutFactory` parameters
from the `build-image` goal in the Maven plugin while retaining
them for the `repackage` goal. The `build-image` goal currently
only supports jar archives, so allowing other layout types to be
configured for the goal could cause confusion.
Fixes gh-24105
Update jar `Handler` fallback logic to directly support Tomcat
'jar:war:file' URLs. This commit allows contents to be accessed without
the JDK needing to extracted the nested jar to the temporary folder.
Closes gh-24553
Update the jar `Handler` class to support a non-reflective fallback
mechanism when possible. The updated code attempts to capture a regular
jar URL before our handler is installed. It can then use that URL as
context when creating the a fallback URL. The JDK jar `Handler` will
be copied from the context URL to the fallback URL.
Without this commit, resolving new Tomcat URLs of the form
`jar:war:file:...` would result in an ugly "Illegal reflective access"
warning.
Fixes gh-18631
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
A test case would fail to accurately capture the contents
of the layers.idx file unless the test project contained
at least one non-project snapshot dependency, which was only
true when the Spring Boot version was a snapshot.
See gh-23463
Update `MetadataCollector` merge logic so that previous items are no
longer added if the current round contains a property of the same name.
Fixes gh-23916
Ensure that metadata sourced from inner-types is not deleted when
performing an incremental compile. Prior to this commit, the source
type was searched using the `Outer$Inner` format. This is not supported
`Elements.getTypeElement` so we now convert the names to `Outer.Inner`.
Closes gh-10886
Docker daemon authorization plugins reject POST or PUT requests that have a
content type `application/json` header but no content length header. This
commit ensures that a content length header is provided in these cases.
This is a cherry-pick of the changes in d5b2836ec9
which were lost in a forward-merge.
Fixes gh-23957
Docker daemon authorization plugins reject POST or PUT requests that have a
content type `application/json` header but no content length header. This
commit ensures that a content length header is provided in these cases.
Fixes gh-22840
This commit removes `<version>` from the Maven Plugin documentation
where it makes sense so that versions aren't hardcoded unnecessarily.
Rather, a plugin or dependency management should be in place so those
are not needed.
Closes gh-23909
Update the `AbstractJarWriter` so that it can directly build the layer
index as entries are written. Prior to this commit, a layer tracking
was handled by a decorator class which was broken because it didn't
override enough methods. Since `AbstractJarWriter` has quite a complex
API, it seems sensible to have it handle the layer index directly,
removing the need for a decorator entirely.
Fixes gh-23801
Previously, when building a layered jar with Maven, dependencies
on modules in the same build 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 Maven to include
dependencies on modules in the same build in the application layer by
default. The XML schema has also been updated to allow the layer to be
customized using new <includeModuleDependencies/> and
<excludeModuleDependencies/> elements rather than relying on including
and excluding them via a group:artifact:version pattern.
Closes gh-23463
This commit adds support for platform API 0.4 when invoking a CNB
builder in the Maven and Gradle plugins. If the builder advertises
that it supports platform API 0.4 then that version will be
requested when invoking lifecycle phases. Otherwise the plugins
will fall back to requesting platform API 0.3.
Requesting platform API 0.4 when invoking builder lifecycle phases
has the primary benefit of making it easier to pass command-line
arguments to the default process in the generated image.
Fixes gh-23692
This commit polishes the javadoc for Maven plugin classes now that
the plugin reference docs link to the javadoc. Visibility of some
MOJO parameter class getters and setters were also changed for
consistency.
See gh-21555
This commit modifies the documentation generated for the
Maven plugin to include links to javadoc when Spring
Boot types are mentioned. Some javadoc was also polished
to improve the generated docs.
Fixes gh-21555
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
The CNB specifications allow builders to support multiple platform
API versions. The supported versions are published in the builder
image metadata as an array of version numbers, while a single
supported version number was published in earlier builder metadata.
These changes read the supported versions from the builder metadata
and fall back to the single version if the array is not present.
A CNB_PLATFORM_API environment variable is set on each lifecycle
phase invocation to request a specific version as recommended in
the CNB platform spec.
Fixes gh-23682
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
Stephane Nicoll
Andy Wilkinson
izeye
Phillip Webb
Scott Frederick
Leo Li
slowjoe007
Julian Liebig
Vedran Pavic
Vincent Ricard
Rafael Ceccone
dreis2211
Jeroen Meijer
Madhura Bhave
Marcus Klimstra
Mark Jeffrey
Slawomir Jaranowski
Abel Salgado Romero
weixsun
Sach Nguyen
Dmitry Pavlov
robert-smith-911
Jurrie Overgoor
Bertrand Renuart
trungPa
jnizet
Stefan Wolf
Scott Frederick
Mustafa Ulu
Robert Smith
Madhura Bhave
jongmin92
Rob Edwards
Valery Yatsynovich
Marten Deinum
Stephane Nicoll
Sebastian Nohn
Kedar Joshi
olivier.antoine
Andy Wilkinson
Emily Casey