Skip to content

Decouple build JDK from test JDK; upgrade shadow to 9.2.2#221

Merged
bigdaz merged 2 commits into
mainfrom
decouple-build-test-jdk
Jul 4, 2026
Merged

Decouple build JDK from test JDK; upgrade shadow to 9.2.2#221
bigdaz merged 2 commits into
mainfrom
decouple-build-test-jdk

Conversation

@bigdaz

@bigdaz bigdaz commented Jul 4, 2026

Copy link
Copy Markdown
Member

Problem

The test-gradle-version matrix 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:

  • Build the plugin fatjar with a fixed, modern JDK (17) in every job.
  • Test the :plugin-test module (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/fromEnv needed. org.gradle.java.installations.auto-download=false guarantees a missing toolchain fails the build loudly rather than being silently provisioned.

With the build freed from old JDKs:

  • Bump shadow 8.3.69.2.2 — the latest that keeps the Gradle 8.14.4 wrapper (shadow 9.3+ requires Gradle 9).
  • Shadow 9 exposes configurations as a SetProperty and ships native auto-relocation, so the manual per-package relocation loop is replaced with enableAutoRelocation + relocationPrefix. Verified the resulting fatjar is structurally equivalent (all bundled deps under org.gradle.shadow., no un-relocated leaks, META-INF/versions stripped).

quick-check and self-test build JDK bumped 11 → 17 (shadow's runtime requirement).

Verification

Both approaches were run green on CI across all 10 matrix rows + quick-check + self-test:

  • With fromEnv (initial commit): full matrix green.
  • Auto-detection only (final commit, fromEnv removed): full matrix green. Conclusive because auto-download=false — the 5.2.1/5.6.4 rows 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 explicit fromEnv is unnecessary.

🤖 Generated with Claude Code

bigdaz and others added 2 commits July 4, 2026 16:33
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>
@bigdaz bigdaz merged commit 3a4c575 into main Jul 4, 2026
16 checks passed
@bigdaz bigdaz deleted the decouple-build-test-jdk branch July 4, 2026 23:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant