Prior to this commit, the Spring Framework build would partially use the
dependency management plugin to import and enforce BOMs.

This commit applies the dependency management plugin to all Java
projects and regroups all version management declaration in the root
`build.gradle` file (versions and exclusions).

Some versions are overridden in specific modules for
backwards-compatibility reasons or extended support.

This commit also adds the Gradle versions plugin that checks for
dependency upgrades in artifact repositories and produces a report; you
can use the following:

    ./gradlew dependencyUpdates

Closes gh-23566

Closes gh-23543

This reverts commit e5b95716.

See gh-23124

This commit makes sure the content of the local maven repository has no
impact on the build

See gh-23124

This commit makes sure we narrow down dependencies of the Spring
Framework to only Maven central. Optional dependencies that are not
available on Maven Central are now served from a more specific
repository (`ext-release-local`).

Closes gh-23124

Closes gh-23536

Closes gh-23535

Since gh-23282, our CI does not apply automatically the Artifactory
Gradle plugin during our build and we're now applying it "manually".
This commit backports this change since the build configuration is
shared between branches.

See gh-23282

take advantage of the symmetrical SocketAcceptor methods now available
on RSocketFactory for both client and server side.

See gh-23282

See gh-23282
See spring-projects/spring-security#7183
Closes gh-23506

Instead of relying on the CI server to apply and configure this plugin,
this commit does it directly in the Spring Framework build.
This allows us to take full control over which projects are published
and how.

See gh-23282

This commit switches to the default publication name considered by the
artifactory plugin when it comes to publishing artifacts to the
artifactory repository.

See gh-23282

Prior to this commit, the build would use a custom task to create a BOM
and manually include/exclude/customize dependencies. It would also use
the "maven" plugin to customize the POM before publication.

This commit now uses a Gradle Java Platform for publishing the Spring
Framework BOM. We're also now using the "maven-publish" plugin to
prepare and customize publications.

This commit also tells the artifactory plugin (which is currently
applied only on the CI) not to publish internal modules.

See gh-23282

Prior to this commit, the Spring Framework build would mix proper
framework modules (spring-* modules published to maven central) and
internal modules such as:
* "spring-framework-bom" (which publishes the Framework BOM with all
modules)
* "spring-core-coroutines" which is an internal modules for Kotlin
compilation only

This commit renames these modules so that they don't start with
"spring-*"; we're also moving the "kotlin-coroutines" module under
"spring-core", since it's merged in the resulting JAR.

See gh-23282

Prior to this commit, the reference documentation build with asciidoctor
would get the common "spring-docs-resources" as a dependency and then
use it when generating the docs.

As seen in #23124, this can cause problems since we'd like to
consistently resolve our dependencies. In this case, the
"spring-doc-resources" archive is not published on maven central since
it's not officially supported by the Spring team as an open source
project.

This commit updates the reference documentation build to get this
archive as a simple download task and avoid resolving it as a
dependency.

See gh-23282

This commit ensures that the spring-framework-bom project is ignored
from the global configuration block. If not, many conventions and
dependencies are added to it and add noise to the published BOM.

See gh-23282

This reverts commit fb0d6187.

This reverts commit 1539ba89.

This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests

With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).

See gh-23282

This commit moves the dependency management and test source files
related to integration tests to a dedicated module.
This allows us to focus the root project on building the Spring
Framework.

See gh-23282

This commit removes JDiff from the Spring Framework build and instead,
adds a Gradle plugin that configure JApiCmp tasks on the framework
modules.

Fixes gh-22942
See gh-23282

This updates brings full interoperability between Reactor and
Coroutines contexts.

Closes gh-22986

Closes gh-23467

This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.

This commit also includes the following.

- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
  Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
  JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
  existing JUnit 4 tests in the spring-test module in order to perform
  assumptions using JUnit 4's Assume class

See gh-23451

This first commit for this issue:

- allows JUnit Jupiter to be used for all tests
- adds a dependency on mockito-junit-jupiter
- migrates tests in spring-core to JUnit Jupiter, except parameterized
  tests

The following script was developed in order to semi-automate the
migration process.

https://github.com/sbrannen/junit-converters/blob/master/junit4ToJUnitJupiter.zsh

See gh-23451

This commit removes unused parts of the Gradle build:
* Gradle wrapper customization which should not be needed in recent
versions of Gradle (or can be replaced with options in the
gradle.properties file)
* the branch strategy configuration

See gh-23282