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
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
This commit removes JDiff from the Spring Framework build and instead,
adds a Gradle plugin that configure JApiCmp tasks on the framework
modules.
Fixes gh-22942
See gh-23282
Prior to this commit, the Spring Framework build would be using the
propdeps Gradle plugin to introduce two new configurations to the build:
"optional" and "provided". This would also configure related conventions
for IDEs, adding those configurations to published POMs.
This commit removes the need for this plugin and creates instead a
custom plugin for an "optional" configuration. While the Eclipse IDE
support is still supported, there is no need for specific conventions
for IntelliJ IDEA anymore.
This new plugin does not introduce the "provided" scope, as
"compileOnly" and "testCompileOnly" are here for that.
Also as of this commit, optional/provided dependencies are not published
with the Spring Framework modules POMs annymore.
Generally, these dependencies do not provide actionable information to
the developers reading / tools consuming the published POMs.
Optional/Provided dependencies are **not**:
* dependencies you can add to enable some supported feature
* dependencies versions that you can use to figure out CVEs or bugs
* dependencies that might be missing in existing Spring applications
In the context of Spring Framework, optional dependencies are just
libraries are Spring is compiling against for various technical reasons.
With that in mind, we are not publishing that information anymore.
See gh-23282
This commit introduces Kotlin code snippets, for now
in the core reference documentation. Other sections
will follow, as well as improvements like global
language switch.
See gh-21778
Sam Brannen
Andy Wilkinson
YuDongYing
Johnny Lim
Brian Clozel
Stephane Nicoll
Sebastien Deleuze