Menu
▾
▴
[Pcgen-github] [PCGen/pcgen] 4589fa: build.gradle: fix clean/download race and merged-m...
|
From: Vest <no...@gi...> - 2026-06-05 21:51:12
|
Branch: refs/heads/master Home: https://github.com/PCGen/pcgen Commit: 4589fa8772e5da2e513c6cc13f8a76d497d771d5 https://github.com/PCGen/pcgen/commit/4589fa8772e5da2e513c6cc13f8a76d497d771d5 Author: Vest <Ve...@us...> Date: 2026-06-06 (Sat, 06 Jun 2026) Changed paths: R apex-ruleset.xml M build.gradle M code/gradle/plugins.gradle R code/sbin/fromdos.exe R installers/release-notes/genreleasenotes.pl R ruleset.xml R xdocs/changes.xml R xdocs/download.xml.vm R xdocs/images/vellum.jpg R xdocs/index.xml R xdocs/stylesheets/maven-pcgen.css Log Message: ----------- build.gradle: fix clean/download race and merged-module missing JDK requires (#7583) * build.gradle: order download tasks after clean to avoid race Running `gradle clean fullJpackage` (or any task graph that combines clean with downloads) could fail with two parallel-execution races: * `:clean` aborts with "Unable to delete directory 'build': New files were found" because `:downloadJdk` / `:downloadJavaFXLocal` were already streaming `.part` files into `build/download-task/` while `:clean` was deleting `build/`. * `:downloadJavaFXLocal` aborts moving its `.part` into `mods/` because `:cleanMods` had just wiped `mods/`. The download tasks had no ordering relative to clean, so Gradle was free to interleave them. Add `mustRunAfter clean` to `:downloadJdk`, `:downloadJfxMods`, and `:downloadJavaFXLocal` — same pattern already used by `:copyToLibs` and `:build` in this file. `mustRunAfter` (rather than `dependsOn`) is the right tool: it only constrains order when both tasks are in the same task graph, so plain `gradle fullJpackage` still works incrementally without forcing an unwanted clean. * build.gradle: list all JDK requires the merged module needs PR #7581 switched mergedModule to `useJdeps = 'exclusively'` to avoid the plugin's default resolver missing JDK modules on Temurin. The fix is incomplete on JDKs that don't ship JDK jmods. The org.beryx.jlink plugin invokes jdeps with `--module-path $javaHome/jmods:$jlinkJarsDir`. On JEP 493 distributions (Temurin 25 macOS/aarch64 in particular) the JDK ships no `.jmod` files for JDK modules — the only `*.jmod` files in `$javaHome/jmods/` are the JavaFX ones we drop in via `:downloadJfxMods`. jdeps therefore resolves `requires javafx.base` etc. but silently omits every JDK requires (java.logging, java.desktop, java.sql, …). The packaged app then dies on launch with: IllegalAccessError: class freemarker.log._JULLoggerFactory (in module net.sourceforge.pcgen.merged.module) cannot access class java.util.logging.Logger (in module java.logging) because module net.sourceforge.pcgen.merged.module does not read module java.logging …before main() runs. SapMachine 25 ships full jmods so jdeps resolves the JDK modules there — the same build worked on some machines and not on others. Add the missing JDK modules to the `mergedModule { … }` block. The plugin's `additive = true` mode appends them on top of jdeps' output, which on the JEP 493 JDKs we use does not contain them — so no duplicate-requires errors. On a hypothetical JDK with full jmods, jdeps would derive the same set and we'd get duplicates; this is acceptable because `:extractJdk` always pulls the configured Temurin distribution (no JDK jmods) into `jdks/jdk_<os>_<arch>` and `$javaHome` for the jpackage flow points there. Verified by clean `gradle clean fullJpackage` on macOS/aarch64 with Temurin 25.0.3: the merged module-info.class lists all required JDK modules and `PcGen.app/Contents/MacOS/PcGen` launches past the freemarker init that previously crashed. * build.gradle: drop stale clean TODO and unused binDir cleanOutput already wipes output/, and binDir = "code/bin" is referenced nowhere else in the build, so the TODO above the clean task no longer reflects the build's state. * plugins.gradle: type createJarTask closure params as String Untyped closure params default to Object, which prevented the IDE from resolving tasks.register(String, Class<T>, ...) and produced a "cannot infer type" warning. All call sites already pass strings, so behavior is unchanged. * build.gradle: pin jlink.javaHome to the downloaded Temurin The org.beryx.jlink plugin's `BaseTask.computeDefaultJavaHome()` falls through to `Util.getDefaultToolchainJavaHome(project)` when neither `badass.jlink.java.home` nor `BADASS_JLINK_JAVA_HOME` are set and the extension's `javaHome` is unset. This means `:createMergedModule`, `:createDelegatingModules`, `:jlink`, `:jpackage` and friends invoke `jdeps`/`javac`/`jlink`/`jpackage` against whichever JDK Gradle's toolchain auto-discovery happens to pick — SapMachine if SDKMAN points there, Temurin in CI, etc. The merged module-info therefore differed between developer machines: SapMachine ships full JDK jmods so jdeps emits a complete `requires` list there, while a local Temurin run goes through the JEP 493 blind spot fixed in 27040dcd1f. Set `jlink.javaHome` to the same path `targetPlatform` uses (the Temurin extracted by `:extractJdk` from Adoptium) so every plugin task sees the same `$javaHome`, and the build behaves identically on every host. The toolchain JDK is still used for `compileJava`/`test`/`run` and IDE debug — those paths are unaffected. The plugin tasks invoke their tools at *execution* time, so they need the extracted Temurin to exist before they run. Wire each plugin task that resolves `javaHomeOrDefault` (`prepareMergedJarsDir`, `createMergedModule`, `createDelegatingModules`, `prepareModulesDir`, `jlink`, `jpackageImage`, `jpackage`, `suggestMergedModuleInfo`) to `dependsOn extractJdk`. Verified by `gradle clean fullJpackage` on macOS/aarch64 with SapMachine as the toolchain JDK: the build picks Temurin for the plugin's `$javaHome` (the `:jlink` log line "java.base module not found in .../jdks/jdk_mac_aarch64/Contents/Home/jmods, assuming the used Java toolchain has enabled JEP 493" confirms it), and `PcGen.app/Contents/MacOS/PcGen` launches cleanly. * build.gradle: drop unused ivy and JBoss repositories The repositories block had two stale entries with TODO comments: - `pc-gen.org/librepo/` (ivy, HTTP-only): hosts only 2018-era snapshots of `PCGen-base` and `PCGen-Formula`, both of which are local Gradle subprojects (`include 'PCGen-base', 'PCGen-Formula'` in settings.gradle, `implementation project(':PCGen-base')` in this file). The HTTP-only TODO was moot — the repo wasn't reached at all. - `repository.jboss.org/nexus/content/repositories/thirdparty-releases` (maven): the comment literally asked "Which libs do we pull from here?". Answer: none — the only mention of `repository.jboss` in the whole codebase was its declaration. Verified by `gradle --refresh-dependencies dependencies` for `runtimeClasspath` (root + both subprojects) and `testRuntimeClasspath` that every artifact resolves from Maven Central alone. * build.gradle: drop redundant comments around mavenCentral * build.gradle: replace Closure.memoize() with explicit cache map `Closure.memoize()` returns a `MemoizeFunction`, which IntelliJ's Groovy static type checker rejects assigning to the inferred `Closure<String>` type of `latestJavaVersion`. The closure works at runtime but the warning is noisy on every IDE open. Replace with a plain `Map` cache + `computeIfAbsent`. Behavior is identical for our use case (single key, the major Java version), and the closure's type stays a normal `Closure` so the type checker is happy. Verified by running `:downloadJavaFXLocal` which exercises `latestJavaVersion(javaVersion)` via Adoptium API and resolves correctly. * build.gradle: remove unnecessary blank line in dependencies section Signed-off-by: Vest <Ve...@us...> * build.gradle: remove unused ext classpath variable and update Class-Path attributes Signed-off-by: Vest <Ve...@us...> * build.gradle: replace segments[1..-1] with Arrays.copyOfRange IntelliJ's Groovy static analyzer cannot resolve getAt(IntRange) on a String[] and flags the range slice as an error. Arrays.copyOfRange is plain Java, equally idiomatic for an array slice, and warning-free. * build.gradle: drop dependencyUpdates plugin and task With this commit we no longer update our dependencies ourselves and rely on GitHub Actions Dependabot to propose dependency upgrades. * build.gradle: cast Arrays.copyOfRange result to String[] IntelliJ's Groovy resolver infers Arrays.copyOfRange's return type as the erased Cloneable & Serializable supertype and cannot match it against the RelativePath(boolean, String...) constructor. The explicit cast is a no-op at runtime but gives the IDE the type it needs. * build.gradle: type eachFile closure parameter as FileCopyDetails Without an explicit type IntelliJ infers the closure parameter as Object, which cascades into Cannot infer argument types hints on fcd.relativePath. Matches the existing typed closure in extractJdk. * Remove unused code/sbin/fromdos.exe Leftover Cygwin CRLF->LF utility from a pre-Gradle build flow. Nothing in the repo references it; line-ending normalization is already handled by Ant's FixCrLfFilter in build.gradle. Companion to commit 12fd0ecf36 ("Remove sbin directory", 2017), which removed the other cygwin binaries from this directory but missed this one. * Remove unused xdocs/ and genreleasenotes.pl xdocs/ is a pre-Gradle Maven-style documentation directory that nothing in the build references: changes.xml last touched 2010-01-07 (maven-scm-plugin) download.xml.vm last touched 2017-03-23 index.xml last touched 2009-08-18 images/vellum.jpg last touched 2006-07-06 stylesheets/... last touched 2017-02-10 genreleasenotes.pl read xdocs/changes.xml to produce HTML release notes, but it has not been functionally edited since 2017 and the release-notes for 6.09.0x and 6.08.00-RC4..RC7 in this directory were authored without it. Removing the script and its input data together so the directory state stays consistent. * Remove unused top-level apex-ruleset.xml and ruleset.xml stubs Both files are 26-byte stubs containing the literal string "code/standards/ruleset.xml" with no XML structure. Nothing in the build references them: PMD's ruleSetFiles in code/gradle/reporting.gradle (and the equivalents in PCGen-base and PCGen-Formula) point directly at code/standards/ruleset.xml. Likely leftovers from an early Maven/Salesforce-Apex tooling attempt that never panned out. * plugins.gradle: drop unused manifestFile and srcJavaDir locals manifestFile pointed at code/manifest, an untracked leftover JAR manifest template that the build never consumes. srcJavaDir was defined but never referenced. Only buildClassesDir, used as the copy source for every plugin jar, remains. --------- Signed-off-by: Vest <Ve...@us...> To unsubscribe from these emails, change your notification settings at https://github.com/PCGen/pcgen/settings/notifications |