From 859a2d97c2ca4e066b617c0b58533aaf1479e836 Mon Sep 17 00:00:00 2001 From: Anthony Stirling <77850077+Frooodle@users.noreply.github.com> Date: Tue, 19 May 2026 15:00:02 +0100 Subject: [PATCH] Always re-resolve JPDFium snapshots in CI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PR rerun against new JPDFium snapshots kept using Gradle's cached versions from earlier runs. Gradle caches 'changing modules' (anything ending in -SNAPSHOT) for 24h by default, and gh run rerun --failed reuses the existing run's Gradle home — so even after publishing a fresh com.stirling:jpdfium-natives-*:1.0.0-SNAPSHOT, the bootJar kept embedding the old natives. cacheChangingModulesFor 0 means every Gradle invocation re-checks the snapshot's maven-metadata.xml and pulls a newer timestamped build if present. cacheDynamicVersionsFor 0 does the same for non-snapshot dynamic versions (e.g. '1.+'). Both are scoped to the subprojects.configurations.all block alongside the existing security force-versions. Trade-off: every Gradle invocation in CI does a HEAD against Maven Central per snapshot dep (4 natives + 1 main jpdfium = 5 small requests). Negligible compared to a download. Reverts naturally when JPDFium ships a tagged release. --- build.gradle | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/build.gradle b/build.gradle index 6253b1442f..3b493e02ac 100644 --- a/build.gradle +++ b/build.gradle @@ -219,6 +219,11 @@ subprojects { // Bouncycastle 1.83 (from bouncycastleVersion variable) resolutionStrategy.force 'org.bouncycastle:bcprov-jdk18on:1.83' resolutionStrategy.force 'org.bouncycastle:bcpkix-jdk18on:1.83' + // JPDFium ships as Maven Central SNAPSHOT during bring-up. Gradle + // caches snapshots for 24h by default, which means CI reruns + jlink + // can pick up stale natives jars. Force re-resolution every build. + resolutionStrategy.cacheChangingModulesFor 0, 'seconds' + resolutionStrategy.cacheDynamicVersionsFor 0, 'seconds' } dependencyManagement {