Commit Graph

22 Commits

Author SHA1 Message Date
Simon Baslé eabb846d07 Improve how the build deals with javadoc invalid references
This commit improves how the build deals with javadoc invalid references
in two ways.

Link/see references that are temporarily invalid during javadoc
generation of individual modules are better masked by using the option
`Xdoclint:syntax` instead of `Xdoclint:none` (warnings were still
visible in some cases, e.g. when individually building the javadoc for
a specific module).

Global javadoc-building task `api` now combines `syntax` and `reference`
`Xdoclint` groups, allowing to raise truly invalid references even when
all the modules have been aggregated.

This commit also fixes the 20+ errors which appeared following the later
change in doclet configuration.

Closes gh-30428
2023-05-16 15:04:10 +02:00
Brian Clozel e9ada8d15c Upgrade JMH build plugins
This commit upgrades the Gradle JMH plugin to 0.6.8 and the companion
JMH version to 1.36.
2022-12-05 13:02:11 +01:00
Brian Clozel acd9016fc3 Create framework-docs module
This commit creates a new "framework-docs" module, which is dedicated to
documentation generation (reference and API docs).
This commit refactors the build configuration and moves the asciidoc
files to a separate location, but does not change the name nor the
nature of published artifacts.

Closes gh-29417
2022-11-02 10:59:12 +01:00
Brian Clozel 6b0f6e9f27 Apply Gradle Test Retry plugin
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.
2022-10-06 13:54:28 +02:00
Brian Clozel cecc0849a8 Upgrade to Gradle 7.2
This commit upgrades Gradle to 7.2.
Gradle configuration names are updated accordingly.
This also upgrades Gradle build plugins.

See gh-26870
2021-09-13 09:37:35 +02:00
Sam Brannen e7b499f7b6 Upgrade to JMH 1.32 and avoid accidental dependency on jopt-simple 4.6
JMH is now implicitly configured to use jopt-simple 5.0.4 instead of 4.6.

This problem was uncovered while fixing gh-27365
2021-09-07 10:45:44 +02:00
Brian Clozel 85eb589c2e Fix Gradle Java Toolchain configuration
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
2021-05-03 15:02:09 +02:00
Brian Clozel a8d553218c Introduce Gradle Toolchain support in build
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
2021-03-15 14:33:41 +01:00
Sam Brannen 3112dc5f81 Improve JMH Jar configuration 2021-01-12 12:27:54 +01:00
Sam Brannen 6b9d5698ce Upgrade to JMH 1.25 2021-01-12 12:27:54 +01:00
Brian Clozel 67547e61c6 Add JMH benchmark infrastructure
Prior to this commit, the Spring Framework test suite would rely only on
"Performance" tests associated with a specific CI build. As outlined in
gh-24830, the way they're built and executed is not working well
anymore.

This commit introduces a new JMH benchmark infrastructure in the build.
The goal here is not to run those benchmarks as part of a CI build, but
rather provide a proper infrastructure for writing and locally running
micro-benchmarks when working on specific optimizations.

This commit adds and configures a Gradle JMH plugin to allow for JMH
benchmark classes in Spring Framework modules (in `src/jmh/java` of each
`spring-*` module). It's also relaxing the checkstyle rules for JMH
classes, especially around Javadoc rules: this code is not meant to
have Javadocs.

Finally, this commit links to a new Wiki page on the project GitHub
repository documenting the infrastructure and helping contributors to
run and design benchmarks.

See gh-24830
2020-05-13 21:29:02 +02:00
Jendrik Johannes 9bd60f6554 Update to Gradle 6.2
- Build Scan plugin is now Gradle Enterprise plugin applied in settings
- Compile task dependencies are now defined through classpath
- Test fixture publication can be disabled through public API

Closes gh-24384
2020-04-28 15:03:03 +02:00
Sam Brannen 22a888b53d Polish test fixture publication skipping config
Thanks to @jjohannes for the tip.

See gh-23550
2020-01-03 14:56:13 +01:00
Sam Brannen d5f0bb23ae Disable publication of test fixture artifacts
Thanks to @melix for providing the code snippet necessary to achieve
this with Gradle 5.6.x.

See gh-23550
2020-01-02 16:01:35 +01:00
Sam Brannen c91dd02905 Delete obsolete TestSourcesPlugin
Since we have migrated to Gradle's built-in test fixture support, the
custom TestSourcesPlugin Gradle plugin is now obsolete.

See gh-23550
2020-01-02 16:01:35 +01:00
Andy Wilkinson cba91ab28e Stop Created-By manifest header from causing a test task cache miss
Previously, when a project's jar was an input into a test task, a
cache hit required the current build to be using the same JDK as the
one that created the cache entry. This was due to the Created-By
entry in the jar's manifest which will vary if JDKs with different
values for the java.version and java.specification.vendor version are
used.

This commit configures normalization of the runtime classpath to ignore
META-INF/MANIFEST.MF, thereby allowing a cache hit when the tests were
previously run on a different JDK than the one being used now. Typically
this is a different update release being used on a CI agent and a
developer's machine. This change will therefore improve the likelihood
of a cache hit once remote caching has been enabled.

Closes gh-23872
2019-10-25 13:52:48 +02:00
Brian Clozel 86c734785d Apply Artifactory Gradle plugin
Instead of relying on the CI server to apply and configure this plugin,
this commit does it directly in the Spring Framework build.
This allows us to take full control over which projects are published
and how.

See gh-23282
2019-08-21 20:15:35 +02:00
Brian Clozel 7902ae4c1f Change Gradle publication name for artifactory
This commit switches to the default publication name considered by the
artifactory plugin when it comes to publishing artifacts to the
artifactory repository.

See gh-23282
2019-08-21 18:42:17 +02:00
Brian Clozel 7ce1f5e652 Configure Maven publications with Gradle
Prior to this commit, the build would use a custom task to create a BOM
and manually include/exclude/customize dependencies. It would also use
the "maven" plugin to customize the POM before publication.

This commit now uses a Gradle Java Platform for publishing the Spring
Framework BOM. We're also now using the "maven-publish" plugin to
prepare and customize publications.

This commit also tells the artifactory plugin (which is currently
applied only on the CI) not to publish internal modules.

See gh-23282
2019-08-21 15:39:51 +02:00
Brian Clozel e9523161f0 Revert "Revert "Refactor Gradle tasks in Spring Framework build""
This reverts commit fb0d618751.
2019-08-20 20:26:43 +02:00
Stephane Nicoll fb0d618751 Revert "Refactor Gradle tasks in Spring Framework build"
This reverts commit 1539ba8991.
2019-08-20 20:07:11 +02:00
Brian Clozel 1539ba8991 Refactor Gradle tasks in Spring Framework build
This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests

With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).

See gh-23282
2019-08-20 18:17:02 +02:00