* [IDEA] Enable Gradle Configuration Cache for Gradle Runner
This should speedup repetitives usages of the Gradle Runner for the majority of test executions
We added a flag to disable it explicitly if it does not work for certain scenarios
Follow up to #99922. Removing `org.gradle.java.installations.fromEnv`
from our `gradle.properties` file had the side effect of breaking the
`RUNTIME_JAVA_HOME` environment variable since Gradle is unaware of this
toolchain. We need to add `RUNTIME_JAVA_HOME` back here so that setting
this environment variable still works and avoid failures like this one:
https://gradle-enterprise.elastic.co/s/gaezgaglsn76o/failure?expanded-stacktrace=WyIwLTEtMiJd#1
* Use toolchain in favor of custom jdk plugin for runtime jdk setup
* Remove logic for Passing runtime java version via JAVAX_HOME
* Cleanup runtime provisioning gradle script
In Java 21 List now extends SequencedCollection, instead of Collection
directly. When resolving methods Painless starts at the defined type,
and iterates up through super classes and interfaces. Unfortunately if a
superinterface was not known, as it is for SequencedCollection since it
is not in the allowed list of classes, method resolution would give up.
This commit adjusts the superinterface interation to continue traversing
until the method is found or no more superinterfaces are found.
fixes#97022
* Differentiate qa project group ids from in production projects
We need to avoid duplicate GADs of gradle subprojects as we have duplicates otherwise.
Ideally we have a notion of a qa project or internal use project mold into our gradle logic. but for now thats probably enough. in the non xpack modules and plugin folder we workaround this issue by only applying the groupId for direct child projects
Removing the custom dependency checksum functionality in favor of Gradle build-in dependency verification support.
- Use sha256 in favor of sha1 as sha1 is not considered safe these days.
Closes https://github.com/elastic/elasticsearch/issues/69736
This introduces the ability to simply configure a java tool chain for elasticsearch java projects to be used.
If an environment variable `JAVA_TOOLCHAIN_HOME `is declared, this JDK will be used as toolChain in elasticsearch.java projects. If JAVA_RUNTIME_HOME is configured, it takes precedence over JAVA_TOOLCHAIN_HOME
for configuring test cluster runtimes.
This should make testing our build with java `ea` versions easier and allows detangling the used compiler jdk from the gradle java runtime.
Latest JDKs are shipping with timezone data 2021a which is also included
in latest joda. In order to have the timezone information consistent in
both joda and java.time joda dependnecy has to be updated
closes#72028
- Updates our build to use the latest Gradle 6.8 release which is the last release
before the major 7.0 release.
- Resolve available gradle versions using built-in toolchain support
- Fixes deprecated usage of JavaInstallationRegistry
- We replace jdk handling in our build to rely on jvm detection provided by the gradle build tool itself.
As we rely on environment variables pointing to jdks we wire this into the gradle jdk detection mechanism
This commit removes the setting of the fork options maximum memory size
in our build plugin and instead adds the value in the gradle.properties
file to be alongside the value set in jvmArgs.
This change is necessary when using parallel compilation as 512m is not
sufficient for parallel compilation on some machines.
We are still seeing rare failures with the Gradle heap set to 1792m,
especially on machines with high core count. Given it appears we are
close to the needed threshold, this commit bumps the heap one more time
to 2 GB.
After we stopped forking the compiler, some folks are running into out
of memory errors. This commit is a bump to the Gradle heap to workaround
these out of memory errors (until we can better understand their
source).
This commit adds a property that will prevent the Gradle daemon from
being used for builds (even if one is running). This is to avoid some
nasty issues (e.g., SIGBUS faults and other mmap diasters) that result
from class loaders not being closed properly.
Some dependencies must be specified in a couple places in the build.
e.g. randomized runner is specified both in buildSrc (for the gradle
wrapper plugin), as well as in the test-framework.
This change creates buildSrc/versions.properties which acts similar to
the set of shared version properties we used to have in the maven parent
pom.
