Introduce NullMarkedExtension for ArchitectureCheck, which provides
functionality to configure packages to ignore in nullability checks and
to enable or disable the extension.
See gh-47596
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
Projects which don't have JSpecify nullability annotations can opt out
by using
architectureCheck {
nullMarked = false
}
in their build.gradle script.
See gh-46587
Replace `DockerImageNames` with a enum and relocate it from the
`testcontainers` to `container` package. The enum now also
becomes a common location that we can use to apply container
configuration such as timeouts.
Closes gh-41164
Co-authored-by: Phillip Webb <phil.webb@broadcom.com>
This commit introduces auto-configuration for the new Elasticsearch
clients that are based upon their new Java client. The new Java
client builds on top of their existing low-level REST client,
replacing the high-level REST client which has been deprecated.
As part of introducing support for the new Elasticsearch client,
the auto-configuration for the templates (both imperative and
reactive) provided by Spring Data has also been updated to use the
new templates that build upon the new Java client.
As part of these changes, support for the high-level REST client and
the old Spring Data Elasticsearch templates has been removed. One
significant change is that the new reactive template is no longer
based on WebClient. As a result, the WebClient-specific configuration
property has been removed.
Closes gh-30647
Closes gh-28597
Closes gh-31755
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, 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
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
Dmytro Nosan
Moritz Halbritter
Phillip Webb
Andy Wilkinson
Scott Frederick
Andy Wilkinson
dreis2211
Stephane Nicoll
Stephane Nicoll
Gerrit Meier
Andy Wilkinson
Phillip Webb