Prior to this commit, the Java 21 and Java 24 multi-release sources in
spring-core could not be developed or tested within Eclipse, since an
Eclipse project supports only a single Java compliance level.
This commit configures Eclipse projects that use the multiReleaseJar
plugin with the highest multi-release version as their Java baseline
(Java 24 for spring-core) and includes the corresponding multi-release
source folders. Types which are overridden by a multi-release source
folder are excluded from lower source folders, and higher source
folders are placed first so that the debugger's source lookup resolves
overriding types.
A lower baseline can be configured via the "eclipseJavaBaseline"
project property: for example, -PeclipseJavaBaseline=17.
See gh-37397
Although the multi-release source sets in spring-core were already
excluded from the Eclipse classpath, their Gradle output directories
(such as build/classes/java/java21) were still added as libraries
once they existed, resulting in duplicate types on the classpath.
This commit removes those entries as well, generalizes the exclusion
to any Java release version, revises the outdated comment in
ide.gradle, and documents the limitation in the Eclipse import
instructions.
See gh-37397
This commit makes use of the Java specification version in the Jar
metadata to make build easier to reproduce on a different environment.
Closes gh-37250
Add missing nullness annotation in
UriComponents.VarArgsTemplateVariables to fix new warnings.
Closes gh-36850
Signed-off-by: Manu Sridharan <msridhar@gmail.com>
After the upgrade to Gradle 9.6.0/9.6.1, the Gradle build started
emitting warnings due to use of deprecated APIs.
For example, Project.getProperties() is now annotated as @Deprecated
in Gradle 9.6 and will be removed in Gradle 10.0.
To avoid the warnings, this commit modifies:
- TestConventions to use `project.findProperty(...)` instead of
`project.getProperties().get(...)`
- framework-api.gradle to use `rootProject.ext.moduleProjects` instead
of simply `moduleProjects`
- framework-api.gradle and framework-bom.gradle to use
`project(<projectX>)` instead of simply `<projectX>`
- ide.gradle so that it no longer uses the deprecated `javaRuntimeName`
See gh-36952
Prior to this commit, module javadoc packages like
"spring-core-7.0.8-javadoc.jar" would contain 4MB of web fonts in the
`resource-files/fonts/` folder. This increases significantly (often
doubles) the size of the javadoc JAR for little value.
With this commit, Web fonts are packaged with the aggregated Javadocs
for the entire Spring Framework project, but are skipped for inidividual
modules.
Closes gh-36889
This commit also replaces Arch Unit packageInfoShouldBeNullMarked() rule
by either configuring requireExplicitNullMarking = false when the whole
module does not have JSpecify annotations, or explicit @NullUnmarked
when some have and some don't.
See gh-36054
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