Setting `options.fork = true` causes the classpath in the forked
compiler process to include Class-Path entries from MANIFEST.MF files
in JARs in the classpath, which results in warnings about missing
classpath entries.
This commit removes the `options.fork = true` declaration and further
simplifies the script.
See gh-24474
0.4.0 provides built-in support for remembering a user's selections
using local storage. This replaces the custom switch language
JavaScript.
The selection is stored using a key derived from the
options that were available. Concretely, when the options are Java or
Kotlin, the local storage key is java-kotlin. Similarly, if the
choices were Java, Kotlin, and XML, the key would be java-kotlin-xml.
Given local storage's domain and protocol scoping, the nature of the
key that's used for storage will allow a user's selections to be
applied across all documentation hosted on https://docs.spring.io that
offer the same options.
Closes gh-24481
Prior to this commit, the "-Werror" was removed as a command-line
argument in order not to fail the build for missing classpath elements.
This commit reinstates "-Werror" and removes "-Xlink:path" in order to
explicitly ignore warnings for missing classpath elements when executing
the build with a custom JAVA_HOME.
See gh-24474
This commit adds support for the following two JVM system properties
that control the Gradle build for alternative JDKs (i.e., a JDK other
than the one used to launch the Gradle process).
- customJavaHome: absolute path to the alternate JDK installation to
use to compile Java code and execute tests. Setting this system
property causes Groovy 3.0 RC3 to be used instead of 2.5.x. This
system property is also used in spring-oxm.gradle to determine
whether JiBX is supported.
- customJavaSourceVersion: Java version supplied to the `--release`
command line flag to control the Java source and target compatibility
version. Supported versions include 9 or higher. Do not set this
system property if Java 8 should be used.
Examples:
./gradlew -DcustomJavaHome=/opt/java/jdk-14 test
./gradlew --no-build-cache -DcustomJavaHome=/opt/java/jdk-14 test
./gradlew -DcustomJavaHome=/opt/java/jdk-14 -DcustomJavaSourceVersion=14 test
See gh-24474
Previously, the Asciidoctor task was not cacheable and generating the
PDF documentation was very slow. To improve build times, the PDF
documentation was not generated for snapshot builds.
The upgrade to 2.4.0 of the Asciidoctor Gradle pluging means that the
Asciidoctor task is now cacheable. As such, its tasks will only run
when the documentation has changed. This should allow PDF
documentation to be published for every build without slowing things
down too much and the cost of generating the documentation will only
be incurred when there is a change to the documentation.
See gh-24216
This commit updates the build to use the latest version of the
Asciidoctor Gradle Plugin. One significant new feature is that the
plugin's tasks are now cacheable.
Closes gh-24216
Previously, the remote build cache was only enabled if the
GRADLE_ENTERPRISE_URL environment variable was configured. This meant
that contributors would not benefit from the build time improvements
of the caching without some additional setup.
This commit updates the buildCache configuration so that reading from
the remote build cache at https://ge.spring.io is enabled for all.
Pushing to the cache continues to be disabled unless the required
credentials are provided. Build scan configuration has also been
updated in line with this change. While the server URL is now
hardcoded, publishing is still opt-in via an environment variable.
The exact mechanism by which someone can opt in will change in the
future once some server-side changes have been made. At this point,
only a change to publishAlwaysIf should be necessary.
Closes gh-24105
Prior to this commit, the schemaZip Gradle task failed to find Spring
schema files on MS Windows due to path separators hard coded to forward
slashes that are not compatible with the Windows operating system.
Consequently, a full build failed on Windows since the distZip task was
not able to locate the zipped schema archive that the schemaZip task
failed to create.
This commit fixes this by updating the schemaZip task to search for
schema files using backslashes as well as forward slashes.
Closes gh-23933
This commit provides opt-in enablement of Gradle's remote build
cache. When the GRADLE_ENTERPRISE_URL environment variable is set, its
build cache node will be used as a source of cached output. If both
GRADLE_ENTERPRISE_CACHE_USERNAME and GRADLE_ENTERPRISE_CACHE_PASSWORD
are also set, task output produced by the build will be pushed to the
build cache node for use by subsequent builds.
Closes gh-23883
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
The parallel forks configuration of Test tasks can have a big impact
on their execution time. This commit updates the build can
configuration to capture each Test task's maxParallelForks
configuration as custom values in the build scan. This will make this
data available when comparing scans which will be useful as we
experiment with different parallel fork settings to reduce the
build's overall execution time.
Closes gh-23691
When exposed as an environment variable Bamboo's bamboo.resultsUrl
is mapped to bamboo_resultsUrl. This commit updates the build scan
user data script to look for the latter rather than the former.
Closes gh-23597
When exposed as an environment variable Bamboo's bamboo.resultsUrl
is mapped to bamboo_resultsUrl. This commit updates the build scan
user data script to look for the latter rather than the former.
This commit adds opt-in build scan integration with Gradle Enterprise.
When the GRADLE_ENTERPRISE_URL environment variable is set on a
developer's machine or on CI, a build scan will be automatically
uploaded to Gradle Enterprise at the end of the build.
This initial integration will establish a baseline for Spring
Framework builds. Once that baseline has been established we can use
the build scans to identify ways in which the build can be optimized
and updated to make use of Gradle's build caching which should reduce
build times, significantly so for changes that only affect tasks near
the leaf nodes of the task graph.
This commit reverts all artifactory configuration changes in this
branch. A new build plan has been created for the master branch which is
tailored for the latest Gradle changes made on that branch.
This commit adds a missing dependency from the artifactoryPublish task
to the "install" task as POMs are currently missing from the published
artifacts and they are generated with the "install" task here.
Since gh-23282, our CI does not apply automatically the Artifactory
Gradle plugin during our build and we're now applying it "manually".
This commit backports this change since the build configuration is
shared between branches.
See gh-23282
This commit ensures that Gradle publications are using resolved
dependency versions for Maven publications (i.e. POMs). This is useful
since we're using the Spring dependency management plugin and we can't
rely on declared dependency versions only.
See gh-23282
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
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
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
This commit configures the Gradle Download plugin that's used a build
step when generating the reference documentation. Here we're making sure
that the task is caching and reusing the resource if it's been
downloaded already.
See gh-23282
Prior to this commit, the reference documentation build with asciidoctor
would get the common "spring-docs-resources" as a dependency and then
use it when generating the docs.
As seen in #23124, this can cause problems since we'd like to
consistently resolve our dependencies. In this case, the
"spring-doc-resources" archive is not published on maven central since
it's not officially supported by the Spring team as an open source
project.
This commit updates the reference documentation build to get this
archive as a simple download task and avoid resolving it as a
dependency.
See gh-23282
Sam Brannen
Andy Wilkinson
Rob Winch
YuDongYing
Johnny Lim
Brian Clozel
Stephane Nicoll