Decouple build JDK from test JDK; upgrade shadow to 9.2.2#221
Merged
Conversation
The CI matrix built the plugin fatjar and ran the TestKit tests with a single JDK per row, pinning the whole build toolchain to the oldest JDK under test (8). That blocked upgrading the shadow plugin, which now requires Java 17+. Split the two concerns: - The plugin fatjar is always built with a fixed, modern JDK (17). - The :plugin-test module compiles and runs on the JDK a given Gradle version requires, selected via a Gradle toolchain (-PtestJavaVersion). The matrix JDKs are already installed on the runner and exposed as JAVA_HOME_<version>_X64; org.gradle.java.installations.fromEnv points Gradle's toolchain detection at them (auto-detection does not scan the runner tool cache on its own). With the build no longer constrained to old JDKs, bump shadow 8.3.6 -> 9.2.2 (keeps the Gradle 8.14.4 wrapper; shadow 9.3+ would require Gradle 9). Shadow 9 exposes `configurations` as a SetProperty and provides native auto-relocation, so the manual per-package relocation loop is replaced with enableAutoRelocation + relocationPrefix, producing an equivalent relocated fatjar. Disable toolchain auto-download so a misconfigured testJavaVersion fails fast instead of silently provisioning a JDK. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Test whether Gradle auto-detects the runner's preinstalled JDKs without org.gradle.java.installations.fromEnv. auto-download stays disabled so a missing toolchain fails the matrix instead of silently downloading one. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
test-gradle-versionmatrix built the plugin fatjar and ran the TestKit tests with a single JDK per row. Because the oldest supported Gradle (5.x) must run on JDK 8, the whole build toolchain — including the shadow plugin — was pinned to JDK 8. That blocked upgrading shadow, whose recent releases require Java 17+.Only the tests actually need the old JDK (old Gradle can't run on new JDKs). The fatjar targets Java 8 bytecode and can be built on any modern JDK.
Change
Split the two concerns:
:plugin-testmodule (and thus the Gradle version under test) on the JDK that version requires, selected via a Gradle toolchain (-PtestJavaVersion). The module is compiled for that JDK too, not just executed on it.The matrix JDKs are already preinstalled on the runner and are found by Gradle's toolchain auto-detection — no explicit
installations.paths/fromEnvneeded.org.gradle.java.installations.auto-download=falseguarantees a missing toolchain fails the build loudly rather than being silently provisioned.With the build freed from old JDKs:
8.3.6→9.2.2— the latest that keeps the Gradle8.14.4wrapper (shadow9.3+requires Gradle 9).configurationsas aSetPropertyand ships native auto-relocation, so the manual per-package relocation loop is replaced withenableAutoRelocation+relocationPrefix. Verified the resulting fatjar is structurally equivalent (all bundled deps underorg.gradle.shadow., no un-relocated leaks,META-INF/versionsstripped).quick-checkandself-testbuild JDK bumped11 → 17(shadow's runtime requirement).Verification
Both approaches were run green on CI across all 10 matrix rows +
quick-check+self-test:fromEnv(initial commit): full matrix green.fromEnvremoved): full matrix green. Conclusive becauseauto-download=false— the5.2.1/5.6.4rows on JDK 8 could only pass if the toolchain genuinely resolved to a preinstalled JDK 8 (old Gradle cannot run on JDK 17). So auto-detection locates the runner's JDKs; the explicitfromEnvis unnecessary.🤖 Generated with Claude Code