This commit upgrades the build to use Gradle 9.2 and reinstates the use
of the Groovy safe-navigation operator (?.) in framework-api.gradle.
See https://github.com/gradle/gradle/issues/35049
See d038269ec3
Closes gh-35713
This commit upgrades the build to use Gradle 9.1.
To achieve that, the following changes were necessary.
- Stop using Groovy safe-navigation operator (?.) in
framework-api.gradle due to a NullPointerException.
- Switch from the io.github.goooler.shadow plugin to the
com.gradleup.shadow plugin, since the former is no longer maintained
and the latter is a fork that replaces it.
Closes gh-35508
To ensure that failures in javadoc tasks do not result in documentation
silently not being generated/published, this commit sets
`failOnError = true` for all javadoc tasks.
See gh-27497
See gh-34774
Closes gh-34837
We now invoke the javadoc tool with "--link-modularity-mismatch info"
in order not to fail the build when encountering warnings such as the
following.
> The code being documented uses packages in the unnamed module, but the
> packages defined in https://junit.org/junit5/docs/5.12.2/api/ are in
> named modules.
Closes gh-27497
This commit replaces use of the deprecated Gradle `task` method with
the new `tasks.register` method.
Closes gh-34617
Signed-off-by: Dmitry Sulman <dmitry.sulman@gmail.com>
This commit revisit the build configuration to enforce the following:
* A single Java toolchain is used consistently with a recent Java
version (here, Java 23) and language level
* the main source is compiled with the Java 17 "-release" target
* Multi-Release classes are compiled with their respective "-release"
target. For now, only "spring-core" ships Java 21 variants.
Closes gh-34507
This commit replaces NullAway package configuration by package-level
`@NullMarked` detection by configuring `NullAway:AnnotatedPackages` to
an empty string.
NullAway configuration should be refined to use a proper flag instead
once uber/NullAway#574 is fixed.
See gh-28797
This commit updates the whole Spring Framework codebase to use JSpecify
annotations instead of Spring null-safety annotations with JSR 305
semantics.
JSpecify provides signficant enhancements such as properly defined
specifications, a canonical dependency with no split-package issue,
better tooling, better Kotlin integration and the capability to specify
generic type, array and varargs element null-safety. Generic type
null-safety is not defined by this commit yet and will be specified
later.
A key difference is that Spring null-safety annotations, following
JSR 305 semantics, apply to fields, parameters and return values,
while JSpecify annotations apply to type usages. That's why this
commit moves nullability annotations closer to the type for fields
and return values.
See gh-28797
Since the me.champeau.mrjar stores Java 21 main and test sources in
non-standard locations, and since we can only use a single JDK within
Eclipse, this commit updates `ide.gradle` to remove `java21` classpath
entries in Eclipse projects.
Our recent switch from the `org.unbroken-dome.xjc` plugin to the
`com.github.bjornvester.xjc` plugin resulted in errors when trying to
import Spring Framework projects into the Eclipse IDE.
This commit fixes those issues as follows.
- @wilkinsona revised the XJC configuration in `spring-oxm.gradle` to
avoid the ConcurrentModificationException encountered when running
`./gradlew eclipse`.
- I added a workaround in `ide.gradle` to manually remove lingering
"main" classpath entries for sources generated by XJC.
Co-authored-by: Andy Wilkinson <andy.wilkinson@broadcom.com>
Closes gh-33264
Sébastien Deleuze