Previously, all tasks in the build were run sequentially. This
commit updates Gradle's properties to build them in parallel where
possible. When using the daemon (recommended) its default max heap is
not sufficient for the demands on a parallel build, therefore this
commit also increases the daemon's max heap.
See gh-23620
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 the changes made in 7bc44a9 so that developers who
do not use the Gradle daemon are not adversely affected by the explicit
JVM args that were introduced in that commit.
Developers who wish to run the build against JDK 9 with the Gradle
daemon can add the following to the gradle.properties file in their
'gradle user home' directory (e.g., ~/.gradle/gradle.properties):
org.gradle.daemon=true
org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m
See also: https://issues.gradle.org/browse/GRADLE-3256
Issue: SPR-12549
This commit adds the following to gradle.properties in order to execute
the Gradle daemon on JDK 9, since Gradle's DaemonParameters
automatically sets the MaxPermSize JVM argument, which is no longer
supported on JDK 9.
org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m
Issue: SPR-12549
Stephane Nicoll
Spring Buildmaster
Andy Wilkinson
Sam Brannen
Phillip Webb