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.
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
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
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.
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
Previously, reflective access to the archiveBaseName property
incorrectly treated the property as a String. It should have been
treated as a Property<String>. This caused an exception to be thrown
and the deprecated baseName property to be used as a fallback.
This commit corrects the reflective access to the archiveBaseName
property. It also updates the tests to fail if a build outputs a
deprecation warning. Tests that use Gradle's Maven plugin have been
updated to expect deprecation warnings when run with Gradle 6.0 where
the plugin is deprecated. Tests that configure an archive's base name
have been updated to use archiveBaseName when running with Gradle 6.0
and later.
Closes gh-18663
Previously, our Gradle plugin was not tested against Gradle 6.0,
a number of deprecation warnings were output when using the plugin
with Gradle 6, and some functionality related to the application
plugin did not work as expected.
This commit tests the plugin against Gradle 6. It also avoids calling
deprecated APIs. The plugin is compatibile against Gradle 4.10 where
the deprecated APIs' replacements are not available so reflection is
used to call the replcaements. Lastly, the way in which the base name
of the boot distribution that is created when the application plugin
is applied has been modified to ensure that it is effective when using
Gradle 6.
Closes gh-18663
Previously, Maven's default behaviour was relied up which resulted
in the artifact ID being appended to each URL as it was inherited.
This behaviour can only be disabled in Maven 3.6 and later, a version
that we cannot use due to an incompatibility with the Flatten Plugin.
This commit works around Maven's default behaviour by defining
properties for the SCM URL, connection, and developer connection and
then explicitly defining the settings in each pom using these
properties. The explicit definition of the properties in each pom
prevents them being inherited from the parent, thereby disabling the
unwanted appending of the artifact ID to the URL.
Fixes gh-18328
Apply checkstyle rule to ensure that private and package private
classes do not have unnecessary public methods. Test classes have
also been unified as much as possible to use default scoped
inner-classes.
Closes gh-7316
Update Gradle archive tasks to ensure that `META-INF/` and
`META-INF/MANIFEST.MF` remain as the first entries of the archive.
Prior to this commit, rewritten archives would violate the implicit
specification of `JarInputStream` that these entries should be first.
Fixes gh-16698
This commit replaces the default Asciidoctor styling with
Spring specific styling.
First, we need to unzip the contents of the Spring Asciidoctor
documentation resources provided by the
`io.spring.docsresources:spring-docs-resources` distribution zip. This
is done in a `/target/refdocs` folder. We then copy all files from
`src/main/asciidoc` to the same location, and then launch the generation
process.
See gh-16327
This commit removes the need for the Kotlin plugin tests to continue
to set the plugin classpath in each test build script. This is
achieved by adding the jars files containing the Kotlin plugin and
its dependencies to the runner's plugin classpath in the same way as
was already done for the dependency management plugin.
Closes gh-14680
Previously, each test build script used a property to configure its
classpath. This commit simplifies the tests by setting the classpath
once on the GradleRunner, thereby removing the need for it to be set in
each test script. It also allows, and, in fact, requires, the use of
the plugins block to apply the Boot plugin under test.
Unfortunately, this doesn't work for the tests for the reaction to the
Kotlin plugin. See the comments in the GradleBuild class and in each
KotlingPluginActionIntegrationTests build script.
See gh-14680
Previously, only the permissions for the scripts in bin/ were set. The
permissions for the files in lib/ were not explicity set, leaving them
with the same permissions as the source files in Gradle's cache. This
has proven to be a little brittle when building in certain
environments, leading to test failures. It also assumes that the
file permissions in Gradle's cache will be appropriate for entries in
a distribution archive. That may not always be a reasonable assumption
to make.
To avoid the above-described problems, this commit updates the copy
spec that's used to add files to lib/ in the archive so that each
file uses 0644 for its permissions.
Closes gh-14158
Due to gradle/gradle#5510, using a lambda for a task action breaks
up-to-date checks in certain circumstances.
This commit updates JavaPluginAction to use an inner-class in place
of a lambda for the action that it adds to JavaCompile tasks. A test
has not been added as it does not appear to be possible to reproduce
it with a TestKit-based test.
Closes gh-14054
Upgrading the JDK 9-based build to use JDK 9.0.4 has revealed that
Gradle 4.0.x doesn't work with it as it fails to parse the 9.0.4
version number.
This commit disables building the Gradle plugin on Java 9 (as we
had already done for Java 10) until we decide what to do
(see gh-12333).
Previously, the JDK 10 build would fail as we build the plugin using
Gradle 4.0.x (the lowest version of Gradle that we support) and
Gradle 4.0.x doesn't work with Java 10.
Upgrading to Gradle 4.1, which appears to work with Java 10, was
considered but rejected for now as it introduces the risk that we
inadvertently use an API that's new in 4.1 and break our 4.0 support.
This commit goes for the extreme option and disables building the
Gradle Plugin when building with JDK.
See gh-12028
Previously, if the project's group, name, or version changed the
BuildInfo task would still be considered up-to-date as the values of
the project's properties were not reflected in the fields of the
BuildInfo instance.
This commit updates BuildInfo to copy the value of the project's
property to the corresponding BuildInfo field when the property is
read using its getter method on BuildInfo.
Closes gh-12266
Previously, the ordering of the entries in an archive produced by
BootJar was different to the ordering of the entries in an archive
produced by BootWar. The latter placed application classes before
any nested jars, whereas the former was the other way around.
This commit updates BootJar to use the same ordering as BootWar and
adds tests to verify that the ordering is the following:
1. Loader classes
2. Application classes (BOOT-INF/classes or WEB-INF/classes)
3. Nested jars (BOOT-INF/lib or WEB-INF/lib)
4. Provided nested jars in a war (WEB-INF/lib-provided)
The tests also verify that the position of a library is not affected
by it requiring unpacking.
See gh-11695
See gh-11696
Stop running apply-plugin tests as part of the build since during a
release the version number will change and the jar will not be
available.
Fixes gh-11857
Update a couple of the `spring-boot-gradle-plugin` sample gradle flies
so that they include the running classpath. The additional lines are
contained within a tag which is ultimately filtered from the final
documentation.
Fixes gh-11857
This commit removes the use of the incubating PropertyState and
Provider API that was introduced in Gradle 4.0 and deprecated in
Gradle 4.3. A not-deprecated-but-still-incubating replacement was
introduced in Gradle 4.3. The short life of PropertyState and Provider
has made me wary of using an incubating Gradle API in our public API
as it may not be stable for long. Therefore, this commit does not move
to the replacement as it is incubating. Instead, it falls back to
using Gradle's convention mapping. This is internal API, but its use
is not part of our public API and I perceive the risk of using it to
be lower than using the deprecated and/or incubating API alternatives.
Closes gh-11640
The Gradle plugin integration tests find their Gradle build scripts
using a naming convention of ${ClassName}-${methodName}.gradle. This
convention led to two gradle scripts with filenames that were long
enough to causes problems on Windows.
This commit renames two test methods to reduce the length of their
names and, therefore, the names of their corresponding Gradle script
files.
Closes gh-10868
Andy Wilkinson
Lukas Cardot
Sebastiaan Fernandez
Scott Frederick
姜为
Stephane Nicoll
EruDev
Martin Chalupa
Jean-Baptiste Nizet
anshlykov
Madhura Bhave
Phillip Webb
Dave Syer
Brian Clozel
Phillip Webb
Paddy Drury
dreis2211
Johnny Lim
Yuyan
Brian Clozel
SaberXu
Hendrig Sellik
Spring Operator
igor-suhorukov
durigon
Eddú Meléndez
Vedran Pavic
danhyun
Rui Figueira