You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Changes made in conjunction with #27497 now require that we generate
Javadoc with JDK 18 or higher in order to make use of the
"--link-modularity-mismatch" flag for the javadoc executable.
This commit sets the toolchain for the javadoc task in the
framework-api module to use JDK 24 for generating Javadoc.
The common javadoc task used by all spring-* modules will be addressed
in a separate commit.
See gh-27497
See gh-34774
In commit 49ef150, I stated that the common javadoc task used by all spring-* modules would be addressed in a separate commit. However, after further investigation I determined that the spring-test Javadoc JAR was published successfully, including links to JUnit 5 Javadoc (which was not previously the case).
The reason is that the javadoc task automatically uses the toolchain configured by our JavaConventions plugin for each spring-* project.
So, it was just the aggregated Javadoc in the framework-api project that did not get generated/published for 7.0.0-M4, and commit 49ef150 already ensures that the javadoc task for the framework-api project has its toolchain set to Java 24 like JavaConventions does.
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-34774Closesgh-34837
This is a regression that was introduced in #27497.
Although we compile sources with a Java 24 toolchain (targeting Java 17 bytecode), we are still using Java 17 to run the Gradle build.
The text was updated successfully, but these errors were encountered: