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
Previously, the runtimeHintsTest task configuration made a cross
project task reference to obtain the jar path of spring-core-test
to use in the -javaagent argument.
With this change, a dedicated configuration exists to resolve the
project artifact without the need to reference the jar task of
spring-core-test.
Closes gh-30838
Previously, an afterEvaluate call was used to read the values of the
runtimeHintsAgent extension and the -javaagent parameter supplied to
the runtimeHintsTest task was evaluated eagerly.
With this change the construction of the -javaagent parameter is
deferred until task execution and the extension properties are
evaluated lazily.
See gh-30838
Prior to this change, a build cache miss would occur in
runtimeHintsTest tasks when executing the build from two different
locations, causing the tasks to re-execute. This was due to an
absolute path to the agent jar being included in the -javaagent
argument supplied to the test JVM process.
This change introduces a RuntimeHintsAgentArgumentProvider allowing
finer grained control over the way Gradle computes the build cache
key. With this change, the contents of the agent jar file are
considered, rather than the absolute file location.
See gh-30838
RuntimeHintsAgentPlugin purpose is to verify that the reflective
invocations expected match the ones performed.
gh-30242 introduces a code path where the reflective invocation
is skipped when running on native.
This issue set the system property "org.graalvm.nativeimage.imagecode"
to "runtime" when running runtime tests with the agent in order to
make sure the code path tested for those tests is the native one.
Closes gh-30422
On windows, the `*` character is not allowed in a directory's name.
When trying to append a glob pattern to a `Path` (`path.resolve("**")`),
if the underlying `Path.getFileSystem()` is windows then an
`InvalidPathException` is thrown.
The NoHttp plugin doesn't really need a `Path` but a glob `String`, so
this commit uses a simple String concatenation in order to append the
wildcard part (with the canonical path separator for good measure).
Closes gh-30355
This commit removes the `-PmainToolchain` option from our build, since
it was not broadly used. Instead, the language level is now configured
in the `JavaConventions` for JDK 17.
The `-PtestToolchain` option is still available for testing Spring
Framework with other JDKs (i.e., compiling and running tests with a JDK
that's not the baseline).
See gh-30339
This commit moves the checkstyle conventions from the build.gradle
script to a buildSrc convention, ensuring that the same configuration is
applied to all checkstyle tasks.
See gh-30339
LocalVariableTableParameterNameDiscoverer is not registered by default anymore now.
Java sources should be compiled with `-parameters` instead (available since Java 8).
Also retaining standard Java parameter names for all of Spring's Kotlin sources now.
Closes gh-29531
This commit upgrades Jackson to 2.14.0-rc2, and uses the new
ByteBufferFeeder in Jackson2Tokenizer.
Unfortunately, because of https://github.com/FasterXML/jackson-core/issues/478,
we had to change the CompilerConventions to suppress class file warnings.
Closes gh-29343
The plugin is configured to detect flaky tests and retry them 3 times
when running on the CI, but still reports failures. This will provide a
standard way to detect flaky tests as failures and successful attempts
are shown in the tests report.
Add a new `ShadowSource` Gradle task and update `spring-core.gradle`
to include source for cglib, javapoet and objenesis.
Closes gh-28892
Co-authored-by: Andy Wilkinson <wilkinsona@vmware.com>
Prior to this commit, the ApiDiff Gradle task would be configured for
all submodules of the Spring Framework project and would assume that
they all existed for the baseline version considered for the API diff.
This would cause issues when:
* the sub-project is not published as it's not an official "spring-*"
module
* the "spring-*" module is new and did not exist for the baseline
version
This commit ensures that only "spring-*" modules are considered for this
task and that we trigger an early resolution of the baseline version -
if the version doesn't exist, a warn message is logged and we assume
that this is a new module, to be compared with an empty configuration.
This commit also renames the "spring-core-graalvm" project to
"graalvm-feature", since this sub-project is not an official module
published to Maven Central, but rather an internal dependency.
Fixes gh-28818
This commit configures the `RuntimeHintsAgent` in the Spring Framework
test suite.
Instead of applying the agent to the entire test suite, and possibly
interfering with other tests, this commit adds a new custom Gradle
plugin that does the following:
* create a new test task named `"runtimeHintsTest"`
* run this task with the runtime hints java agent
* only execute tests tagged with `"RuntimeHintsTests"`
See gh-27981
Prior to this commit, the `apiDiff` custom Gradle task would only use
the configured repositories in the build to generated the API diff
report. This causes issues when the report has to be generated against a
previous milestone: the Spring Framework build only relies on Maven
Central and a specific `libs-spring-framework-build` repository for
building the project. In this case, the task cannot resolve the previous
milestone artifacts to generate the report.
This commit improves the `ApiDiffPlugin` to automatically add the Spring
Milestone repository to the root project configuration when the task is
executed.
Fixes gh-27928
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
To support the recent changes to our `optional` dependencies plugin,
this commit removes the Eclipse-specific code which no longer appears
to be necessary.
Closes gh-27365
This allows the attributes configured on compileClasspath and
runtimeClasspath to independently influence the variant selection when
resolving the optional configuration, allowing it to contribute compile
dependencies (JAVA_API) to the former and runtime dependencies
(JAVA_RUNTIME) to the latter.
Fixes gh-27365
Previously, the optional configuration had no usage attribute. This
resulted in it using the default, JAVA_RUNTIME, which caused it to
only consume the runtime produced by its dependencies and not the
API. Given that the optional configuration is added to the compile
classpath, this was incorrect.
This commit updates the optional configuration to be configured to
consume the Java API of its dependencies. The configuration has
also been marked as not being for consumption. This prevents other
projects attempting to consume the optional variant of a project
that has the optional dependencies plugin applied and further
aligns it with Gradle's built-in configurations of a similar nature.
See gh-27365
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
Sam Brannen
Brian Clozel
Eric Haag
Juergen Hoeller
Rob Winch
Sébastien Deleuze
Simon Baslé
Arjen Poutsma
Phillip Webb
Sam Brannen
Andy Wilkinson
Brian Clozel
陈其苗
Sam Brannen