Prior to this commit, the Spring Framework build would publish several
zip artifacts:
* a "*-schema.zip" containing all the XSD schemas produced
* a "*-docs.zip" containing the API docs
* a "*-dist.zip" containing all of the above, plus module jars
Since the reference docs are now produced by Antora in a separate
process, the "*-docs.zip" does not contain the reference docs anymore.
But it still contains the API docs which are automatically fetched from
the artifact repository and published on the docs.spring.io website.
This commit intends to update the current arrangement and optimize the
build.
First, the "*-dist.zip" is not published anymore, since it cannot be
consumed anyway by the community: repo.spring.io does not distribute
release artifacts publicly, developers are expected to get them from
Maven Central. This arrangement is quite dated anyway and is not really
useful in current application build setups.
The generation of API docs is moved to a new "framework-api" module,
separating it from the reference docs module ("framework-docs") which
contains Java, Kotlin and Asciidoctor sources. This removes the custom
javadoc aggregation task and instead uses a dedicated Gradle plugin.
This change also adds a new `-PskipDocs` Gradle project property that
skips entirely the documentation tasks (javadoc, kdocs) as well as the
"distrbution" tasks managed in the framework-api module.
This allows developers to publish locally a SNAPSHOT of Spring Framework
without creating the entire documentation distribution. This is
particularly useful for local testing.
For example, `$ ./gradlew pTML -PskipDocs`.
Closes gh-31049
This commit aligns the Artifactory configuration with the changes
applied in gh-29417.
In order to be deployed, docs artifacts must have specific properties
attached to them.
See gh-29417
This commit upgrades the CI pipeline with the following:
* replace JDK16 with JDK17 as build variant
* upgrade all JDK versions
* replace docker-image with registry-image resource for CI image
This commit adds a new JDK 18 variant to the CI build image and
configures a JDK18 build (sources compiled with JDK17, tests compiled
and run with JDK18) to the CI pipeline.
Closes gh-27607
This commit introduces a new `spring-framework-6.0.x` CI pipeline with
JDK 17 baseline.
Note that Kotlin still uses a JDK11 baseline for now, this will be
addressed in gh-27413.
Closes gh-27409
Prior to this commit, the task parameters for the CI project checks were
overridden by a task anchor. This commit splits the anchor declaration
and ensures that the `TEST_TOOLCHAIN` setting is set for the JDK
variant builds.
See gh-25787
This commit fixes various issues with the configuration of the Gradle
Java toolchain in the build.
First, the configuration of build properties is fixed in the CI pipeline
because it wasn't properly checked.
The JMH plugin is also upgraded and we now configure its toolchain
support.
This commit also rewrites the XJC tasks in the spring-oxm module,
leveraging a Gradle plugin that creates actual compile tasks we can
configure.
See gh-25787
This commit fixes the missing pieces in our Maven Central publication
pipeline. Our first attempt at releasing with it showed a few problems:
* the promote task did not have the artifacts downladed with the
artifactory repository
* we applied the wrong Sonatype credentials to the task
* the github changelog task would fail because of docker rate limiting
since we were not using the right type of resource, which is
configured with the proper caching mechanism
See gh-26654
Prior to this commit, the Spring Framework build would rely on
setting a custom Java HOME for building all sources and tests
with that JDK.
This approach is not flexible enough, since we would be testing
the source compatibility against a recent JDK, but not a common
case experienced by the community: compiling and running
application code with a recent JDK and the official, JDK8-based
Framework artifacts.
This method is also limiting our choice of JDKs to the ones
currently supported by Gradle itself.
This commit introduces the support of Gradle JVM Toolchains in
the Spring Framework build.
We can now select a specific JDK for compiling the main
SourceSets (Java, Groovy and Kotlin) and another one for
compiling and running the test SourceSets:
`./gradlew check -PmainToolChain=8 -PtestToolchain=15`
Gradle will automatically find the JDKs present on the host or
download one automcatically. You can find out about the ones
installed on your host using:
`./gradlew -q javaToolchains`
Finally, this commit also refactors the CI infrastructure to:
* only have a single CI image (with all the supported JDKs)
* use this new feature to compile with JDK8 but test it
against JDK11 and JDK15.
Closes gh-25787
This commit skips the Bintray-related tasks in our CI pipeline and
instead relies on Maven Central for publishing Spring Framework
artifacts.
This commit also updates the CI pipeline to sign the artifacts directly
with the `artifactory-resource`.
Closes gh-26654
This commit adds new tasks to the release pipeline, generating release
notes automatically using the issues in the current milestone and
pushing that as the content of the GitHub release.
Closes gh-25922
Brian Clozel
Stéphane Nicoll
Brian Clozel
Stephane Nicoll