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
Previously, our conventions configured the source and target
compatibility on the project's JavaCompile tasks. This causes the
settings to be missed when importing the projects into Eclipse [1].
This commit updates the conventions to set the source and target
compatibility on the project-wide JavaPluginExtension. This allows
the Eclipse import to correctly detect and honour the settings.
Closes gh-26932
[1] https://github.com/eclipse/buildship/issues/978
While we're building with Gradle 6.9 at the moment and ConfigureUtil
has only been deprecated in Gradle 7.1, it doesn't do any harm to
stop using it now.
Closes gh-26928
The previous workaround worked but prevented caching of every test
task as the value of system property pointing to the custom security
properties file varied from build to build.
This commit refines the workaround to copy the file into the build
directory of the test task's project and reference it using a URL
that's relative to the task's working directory. This ensures that
the value of the system property doesn't change from build to build.
Closes gh-26252
Previously a number of file- or directory-based task inputs were
configured with specifying their path sensitivity. This meant
that the default absolute path sensitivity was used. For caches
that are cacheable this would result in a cache miss when the
inputs were identical other than being located at a different
absolute path as they are when running a CI build vs a local build.
This commit updates the configuration of additional task inputs
to use relative path sensitivity. A property name for each input has
also been configured. This makes them easier to identify in build
scans.
Closes gh-26270
sun.security.x509.AlgorithmId.get(String) isn't thread-safe and can
lead to null be returned for an algorithm that should be present.
This commit aims to work around this problem by avoiding the call
to AlgorithmId.get(String). It does so by configuring the
PKCS12 key protection algorithm to one that starts with
pbewithhmacsha (case insensitive). This short-circuits the logic
in PKCS12KeyStore.mapPBEAlgorithmToOID(String) and avoids the call to
AlgorithmId.get(String). Thanks again to @dreis2211 for the
suggestion.
The work around is only used when building with Java 8 as the problem
was fixed in Java 9.
Closes gh-26252
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 adds a new `spring.netty.leak-detection` configuration
property that selects the level of memory leak detection for the Netty
engine.
This configuration is applied statically to Netty; this means all
(non-shaded) Netty usages as client or server will be impacted by this
change.
Developers might use this property during development or tests to find
causes of memory leaks when dealing with Netty buffers.
Closes gh-14338
Previously, the auto-configuration for DataSource initialization and
the properties used to configure it were part of the general
DataSource auto-configuration and properties.
This commit moves the auto-configuration of DataSource initialization
out into a separate top-level auto-configuration class. Similarly,
the properties for configuring DataSource initialization have been
moved from `spring.datasource.*` into `spring.sql.init.*`.
The old initialization-related `spring.datasource.*` properties have
been deprecated but can still be used. When they are used, they new,
separate initialization auto-configuration will back off. In other
words, the initialization related `spring.datasource.*` properties
and the `spring.sql.init.*` properties cannot be used in combination.
Closes gh-25323
Previously, UpgradeApplicator would open build.gradle
using open options that left the fields existing content intact. It
would then write the new content at the beginning of the file. If
the new content was n bytes shorter than the existing content, this
would leave n bytes of the existing content at the end of the file.
This commit updates UpgradeApplicator to truncate the existing file
when it opens it. This ensures that the existing content is
completely replaced by the new content, irrespective of their lengths.
Closes gh-25256
Previously, the main jar file and the source and javadoc jar files all
had the same changes applied to their manifests.
The commit changes the Implementation-Title of source and javadoc jars
so that the title indicates that's what they are. Rather than using
the project's description as the title (as is done for the main jar),
the titles for source and javadoc jars will now be "Source for
${project.name}" and "Javadoc for ${project.name}" respectively.
Closes gh-23974
Previously, the locale context resolver used with WebFlux could only be
configured by provided a custom LocaleContextResolver bean. By
constrast, when using Spring MVC, the spring.mvc.locale and
spring.mvc.locale-resolver properties could be used to configure the
locale and the resolver (fixed or Accept header) respectively.
This commit introduces spring.web.locale and spring.web.locale-resolver
properties and deprecates their spring.mvc equivalents. The new
properties can be used to configure locale resolution with either
Spring MVC or WebFlux.
Closes gh-23449
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
There's a bug in some versions of AsciidoctorJ where extensions are
only called on this first conversion performed by a given Asciidoctor
instance. This affects the multi-page documentation where there are
multiple conversions performed – one for each page in the
documentation.
This commit upgrades the version of AsciidoctorJ used by the
Asciidoctor Gradle plugin to 2.4.1, which contains fix for the problem.
Closes gh-23709
The version of Spring Boot should not be modifiable by a property,
only being using a different version of spring-boot-dependencies or
spring-boot-starter-parent.
Fixes gh-23174
Previously, the Maven plugin integration tests used a settings.xml file
that defined https://repo.spring.io/snapshot as a repository. This
allowed them to resolve snapshots of the plugin's Spring Framework
dependencies but it had the unfortunate side-effect of also allowing
them to resolve snapshots of other Spring Boot modules from Artifactory
rather than using those currently being built.
This commit replaces the repositories in settings.xml with a Gradle
task that resolves the necessary dependencies and populates a local
repository with the dependencies' jars and pom files. This is achieved
using a ComponentMetadataRule that creates a custom variant of each
dependency that includes its pom file, inspired by the example in
gradle/gradle/#11449. A configuration that extends the
runtimeClasspath configuration and select the custom variant via its
attribute is then used to resolve the jars and pom files of the runtime
classpath such that they can then be used to populate the local
repository.
Closes gh-22828
This commit also switches to RSocket SNAPSHOTs and updates the
repository configuration to rely on "libs-snapshot", since the RSocket
SNAPSHOTs are mirrored there.
See gh-22640
This commit adds the support for creating a managed instance of the
Neo4j Java driver. The low-level support for Neo4j is helpful in
situations where the high-level abstraction of Spring Data Neo4j is not
needed.
See gh-22301
Previously, spring-boot-docs used the java-base-plugin and then added
configuration on top. This has proven to be error prone, with the most
recent problem being that the tests were not being compiled and run.
This commit changes approach and applies the java plugin to the project
instead of the java-base plugin. Now, rather than adding the necessary
configuration to the base, the unwanted pieces of the java plugin's
configuration – specifically the jar and javadoc tasks – are disabled
instead. The DeployedPlugin has also been updated so that it does not
create a publication from the java component for projects that have a
disabled jar task.
Closes gh-22284
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
Previously, the retry plugin was only applied on CI as we do not want
tests to be retried in local builds. Unfortunately, this arrangement
led to test tasks from CI builds having additional doFirst and doLast
actions and an additional property. These differences meant that the
output from a test task that has run on CI could not be used by a
local build.
This commit changes our configuration of the test retry plugin so
that it is now always applied. To retain the behaviour of only
retrying tests on CI, max retries is configured to 3 on CI and 0 for
local builds.
Closes gh-21698
Previously, the files were extracted on the fly and written into the
jars. This didn't work well with Gradle's up-to-date checks as the
inputs of the jar task were not well-defined.
This commit moves the extraction of the notice and license files into
a separate task, the outputs of which are then copied into the jar's
META-INF.
Closes gh-21592
This commit updates the MavenPublishingConventions to use HTTPS to
link to the Apache license. The configuration of NoHTTP has also
been reworked so that it will correctly find usch uses of http://
URLs.
Closes gh-21459
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
This commit adds auto-configuration for R2DBC. If R2DBC is on the
classpath, a `ConnectionFactory` is created similarly to the algorithm
used to create a `DataSource`.
If an url is specified, it is used to determine the R2DBC driver and
database location. If not, an embedded database is started (with only
support of H2 via r2dbc-h2). If none of those succeed, an exception is
thrown that is handled by a dedicated FailureAnalyzer.
To clearly separate reactive from imperative access, a `DataSource` is
not auto-configured if a `ConnectionFactory` is present. This makes sure
that any auto-configuration that relies on the presence of a
`DataSource` backs off.
There is no dedicated database initialization at the moment but it is
possible to configure flyway or liquibase to create a local `DataSource`
for the duration of the migration. Alternatively, if Spring Data R2DBC
is on the classpath, a `ResourceDatabasePopulator` bean can be defined
with the scripts to execute on startup.
See gh-19988
Co-authored-by: Mark Paluch <mpaluch@pivotal.io>
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
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
The way in which we deploy the artifacts (publishing to a Maven
repository on the filesystem and then using the Concourse artifactory
resource to upload them) is incompatible with Gradle's module metadata
generation.
The metadata contains an entry, url, that contains the name of the
artifact. This will be something like
spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1.jar. The -1 in
the name is derived from the Maven snapshot build number. It's -1 as
the local repository to which the artifact is published is empty and
has no maven-metadata.xml file. When the artifact is uploaded to
Artifactory there is a maven-metadata.xml file so the build number is
different. As a result, the module metadata points to a file that
doesn't exist. This leads to problems like this when trying to consume
the snapshots:
Could not find spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1-2.3.0.BUILD-SNAPSHOT.jar (org.springframework.boot:spring-boot-gradle-plugin:2.3.0.BUILD-SNAPSHOT:20200114.101952-123)
Gradle has used the maven-metadata.xml file on the server to determine
that 2.3.0.BUILD-SNAPSHOT:20200114.101952-123 is the latest version.
It has downloaded the .module file with this version but it points to
spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1.jar. That file
doesn't exist so the build fails.
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
Andy Wilkinson
dreis2211
Scott Frederick
Phillip Webb
Stephane Nicoll
Brian Clozel
izeye
Mustafa Ulu
Vitalii Mahas
Stephane Nicoll
Scott Frederick
Andy Wilkinson
Gerrit Meier
Phillip Webb
Brian Clozel
Mike Smithson
Vedran Pavic