Skip to content

Update build scripts to Gradle 9.4.1 from 8.14.4#11272

Draft
AlexeyKuznetsov-DD wants to merge 3 commits intomasterfrom
alexeyk/gradle-9
Draft

Update build scripts to Gradle 9.4.1 from 8.14.4#11272
AlexeyKuznetsov-DD wants to merge 3 commits intomasterfrom
alexeyk/gradle-9

Conversation

@AlexeyKuznetsov-DD
Copy link
Copy Markdown
Contributor

DO NOT MERGE, experimenting

What Does This Do

Motivation

Additional Notes

Contributor Checklist

Jira ticket: [PROJ-IDENT]

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.

Copy link
Copy Markdown
Contributor

@bric3 bric3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only reviewed commit 1274a6f, there's some nice fixes, and ideas that align with previous work in #10402, there's also fixes that I don't think are useful for Gradle 9 migration like:

-  def javaDir = buildDir.toPath().resolve("generated/sources/tries/java/${sourceSetName}")
+  def javaDir = project.layout.buildDirectory.dir("generated/sources/tries/java/${sourceSetName}")

This commit alone touches a lot of files. Some changes can be split to smaller PRs.

I'm weighing on toggling off failOnNoDiscoveredTests, maybe there's some "file" detection to add in the addTestSuite methods.

// Only change test JVM if it's not the one we are running the gradle build with
if ((jvmSpec as? SpecificInstallationToolchainSpec)?.javaHome == currentJavaHomePath.get()) {
project.providers.provider<JavaLauncher?> { null }
project.objects.property(JavaLauncher::class.java)
Copy link
Copy Markdown
Contributor

@bric3 bric3 May 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: One of the changes in Gradle 9 is that properties do no allow null anymore. Maybe something better can be used there.

test {
java {
srcDirs += ["$buildDir/generated/source/proto/test/java"]
srcDir tasks.named("generateTestProto").map { "${it.outputBaseDir}/java" }
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: This might be eager. So we might need to use a different approach.

description = 'Copy metrics.yaml files from integrations-core into resources'
inputDirectory = file("$projectDir/integrations-core")
outputDirectory = file("$buildDir/integrations-core-resources")
outputDirectory = layout.buildDirectory.dir("integrations-core-resources").get().asFile
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: I see .get() here, I believe this could be improvement to rewrite the CopyMetricConfigsTask to use providers instead.

testJvmConstraints {
minJavaVersion = JavaVersion.VERSION_21
}
failOnNoDiscoveredTests = false
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: I've seen this as well albeit not when trying Gradle 9.3 on dd-trace-java, IIRC... I think a better solution is to add that flag within the logic of addTestSuiteExtendingForDir, addTestSuiteForDir, this could prevent adding this every time these test suite methods are used.

// dependency 'log4j-over-slf4j' brought in by :dd-java-agent:testing which would shadow
// the log4j module under test using a proxy to slf4j instead.
testCompile.exclude group: 'org.slf4j', module: 'log4j-over-slf4j'
testImplementation.exclude group: 'org.slf4j', module: 'log4j-over-slf4j'
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: What was the problem with testConmpile ?

Comment on lines +4 to +11
// Gradle 9 daemon JVM is JDK 17, but this WAR is deployed to a WildFly server
// that may run on Java 8 (testJvmConstraints maxJavaVersion=11). Pin a Java 8
// toolchain so the produced bytecode loads on the lowest supported test JVM.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(8)
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: interesting 🤔

Comment on lines +56 to +70
// define the task that builds the EAR via a sub-Gradle invocation.
//
// The sub-build inherits this project's wrapper (Gradle 9.4.1), whose daemon
// requires JDK 17 — that's why JAVA_HOME is 17, not the test runtime version.
// The deployed WAR's compile target is pinned separately in
// spring-ear/war/build.gradle via a Java toolchain.
tasks.register('earBuild', Exec) {
workingDir "$appDir"
environment += [
"GRADLE_OPTS": "-Dorg.gradle.jvmargs='-Xmx512M'",
"JAVA_HOME": getLazyJavaHomeFor(8)
"JAVA_HOME": getLazyJavaHomeFor(17)
]
commandLine "$rootDir/${gradlewCommand}", "assemble", "--no-daemon", "--max-workers=4", "-PappBuildDir=$appBuildDir", "-PapiJar=${project(':dd-trace-api').tasks.jar.archiveFile.get()}"
commandLine "$rootDir/${gradlewCommand}", "assemble", "--no-daemon", "--max-workers=4",
"-PappBuildDir=${appBuildDir.get().asFile.absolutePath}",
"-PapiJar=${project(':dd-trace-api').tasks.jar.archiveFile.get().asFile.absolutePath}"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: We may need a more general way to invoke Gradle for sub projects. Actually, even relying on an older Gradle distribution is on the table.

Comment thread gradle/publish.gradle

project.configurations.api.allDependencies.each {
if ((it instanceof ProjectDependency) || !(it instanceof SelfResolvingDependency)) {
if (it instanceof ModuleDependency) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion:

Suggested change
if (it instanceof ModuleDependency) {
if (it instanceof ProjectDependency || it instanceof ExternalModuleDependency) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Let's avoid again another script plugin, this could be a correct convention plugin dedicated for smoke tests.

Also, spring-boot-plugin.gradle and this can be "merged" as a single plugin.

Comment thread gradle/version.gradle
Comment on lines +16 to +20
def stderr = new ByteArrayOutputStream()
def process = new ProcessBuilder('git', 'rev-parse', '--short', 'HEAD').start()
process.waitForProcessOutput(stdout, stderr)
if (process.exitValue() != 0) {
throw new GradleException("Unable to determine git hash: ${stderr.toString().trim()}")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: this is the wrong fix

@bric3
Copy link
Copy Markdown
Contributor

bric3 commented May 5, 2026

Also, did bumping to Groovy 4 was needed to make everything work ?

@AlexeyKuznetsov-DD
Copy link
Copy Markdown
Contributor Author

Also, did bumping to Groovy 4 was needed to make everything work ?

@bric3 If I recall correctly I have to bump codenark and also smoke tests for gradle are using gradleTestKit()
But probably we can keep Groovy 3 with manual override where needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants