This commit reverts all artifactory configuration changes in this
branch. A new build plan has been created for the master branch which is
tailored for the latest Gradle changes made on that branch.
Prior to this commit, tests in spring-web and spring-webflux were no
longer executed due to the removal of the Hamcrest dependency in
commit bb03cdf5d0.
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
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
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
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 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 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
Brian Clozel
Rossen Stoyanchev
Sam Brannen
Sebastien Deleuze
Stephane Nicoll
Lars Grefer
Phillip Webb