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

This commit moves the compile configuration from the Gradle DSL to a
convention. This configuration is not changing often, and we're using
that opportunity to make the Java source compatibility a project
property so as to easily recent JDKs this on the command line.

See gh-23282

Prior to this commit, the Spring Framework build would be using the
propdeps Gradle plugin to introduce two new configurations to the build:
"optional" and "provided". This would also configure related conventions
for IDEs, adding those configurations to published POMs.

This commit removes the need for this plugin and creates instead a
custom plugin for an "optional" configuration. While the Eclipse IDE
support is still supported, there is no need for specific conventions
for IntelliJ IDEA anymore.
This new plugin does not introduce the "provided" scope, as
"compileOnly" and "testCompileOnly" are here for that.

Also as of this commit, optional/provided dependencies are not published
with the Spring Framework modules POMs annymore.
Generally, these dependencies do not provide actionable information to
the developers reading / tools consuming the published POMs.

Optional/Provided dependencies are **not**:
* dependencies you can add to enable some supported feature
* dependencies versions that you can use to figure out CVEs or bugs
* dependencies that might be missing in existing Spring applications

In the context of Spring Framework, optional dependencies are just
libraries are Spring is compiling against for various technical reasons.
With that in mind, we are not publishing that information anymore.

See gh-23282

This commit moves the existing "test sources" Gradle plugin from Groovy
to Java and updates the "buildSrc" build file to prepare for additional
plugins in the Spring Framework build.

The plugin itself looks, for a given Spring Framework module, at all the
project dependencies for the following scopes: "compile", "testCompile",
"api", "implementation" and "optional" (to be supported by a different
plugin).

See gh-23282

This commit introduces Kotlin code snippets, for now
in the core reference documentation. Other sections
will follow, as well as improvements like global
language switch.

See gh-21778

Closes gh-23359

Run with snapshots in preparation for next week's releases.

Commit eec183ef configured the
Artifactory Gradle task in the Default Job of the Bamboo build plan for
the Spring Framework (SPR-PUB) to use the following Gradle-friendly test
results directory pattern: `**/build/test-results/**/*.xml`.

That change made the existing custom configuration of the test results
directory in the common Gradle `test` task obsolete.

This commit upgrades Coroutines support to kotlinx.coroutines
1.3.0-RC, leverages the new Coroutines BOM and refine Coroutines
detection to avoid false positives.

Only Coroutines to Mono context interoperability is supported
for now.

CLoses gh-23326

Includes updated javadoc links for 5.1.x branch.

See gh-23076

Close gh-23316