[Pcgen-github] [PCGen/pcgen] e2539b: Build cleanup: distribution / plugins / release.gr...

[Vest <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/PCGen/pcgen
  Commit: e2539b7371d99b5f7b2517393a9c01519a2ede21
      https://github.com/PCGen/pcgen/commit/e2539b7371d99b5f7b2517393a9c01519a2ede21
  Author: Vest <Ve...@us...>
  Date:   2026-06-06 (Sat, 06 Jun 2026)

  Changed paths:
    M build.gradle
    M code/gradle/distribution.gradle
    M code/gradle/plugins.gradle
    M code/gradle/release.gradle
    R code/src/java/plugin/exporttokens/manifest.mf
    R code/src/java/plugin/lsttokens/manifest.mf

  Log Message:
  -----------
  Build cleanup: distribution / plugins / release.gradle drive-by fixes (#7585)

* distribution.gradle: throw on JavaFX cleanup failure instead of swallowing it

The previous form
'installLibDir.listFiles()?.findAll { ... }?.each { it.delete() }'
ignores the boolean returned by File.delete(). If a JavaFX jar is
locked (running JVM, antivirus, IDE holding the file handle) the
delete silently fails and the wrong jar ends up in the dist.

Now check the boolean and throw a GradleException -- the failure is
visible immediately instead of producing a broken installer. Uses
File.listFiles + File.delete (instead of Gradle's fileTree/project.delete)
to stay compatible with the configuration cache.

* distribution.gradle: drop dead .sh chmod hook in programScriptImage

The 'eachFile { if .endsWith(".sh") setMode(0755) }' branch only
fires for files matched by the enclosing 'from("code") { include
"LICENSE" }', so it never matches anything -- the unix start
script (code/pcgen.sh) is generated by the application plugin and
flows through a different copy spec.

Removing the hook also removes the deprecated FileCopyDetails.setMode(int)
call, which is replaced by FileCopyDetails.permissions { ... } in modern
Gradle.

* Remove orphan manifest.mf fragments under plugin/ source tree

Both files contain only 'Class-Path: lib/pcgen.jar', which is now set
dynamically by the createJarTask helper in code/gradle/plugins.gradle.
No build script, manifest, or resource references these paths -- they
are leftover fragments from the pre-Gradle build system.

* plugins.gradle: depend on 'classes' instead of 'compileJava'

'classes' is the conventional Gradle aggregator that depends on
compileJava + processResources. Today the plugin source tree is
.java only, so the two are equivalent, but if any plugin/ subtree
ever gains a resource file the current 'compileJava' dependency
would race processResources and miss it.

* release.gradle: drop redundant 'apply plugin: java'

The main build.gradle applies the 'application' plugin to the root
project, which transitively applies 'java'. release.gradle is loaded
into the same project via 'apply from:', so re-applying 'java' here
is a no-op.

* distribution.gradle: also delete dot-named JavaFX jars from installDist

The cleanup previously matched only 'javafx-*' (dash-named jars from
Maven coordinates). With the application plugin's current
configuration, JavaFX is pulled in as 'javafx.base.jar',
'javafx.graphics.jar', etc., so the cleanup silently no-op'd and the
jars shipped in build/install/pcgen/lib/ -- enough to load the JavaFX
classes but not the native graphics pipeline, producing a
'QuantumRenderer: no suitable pipeline found' at runtime.

Match both 'javafx-*' and 'javafx.*' to cover either naming.

* build.gradle: sweep .DS_Store before jpackageImage rmtree

On macOS, Finder lazily writes .DS_Store into any directory it has
previewed. If one appears under build/jpackage between the jlink
plugin listing the directory and recursively deleting it, the rmtree
fails with:

  New files were found. This might happen because a process is still
  writing to the target directory.
  - .../build/jpackage/.DS_Store

Sweep the file out in a doFirst before the plugin's delete runs.
Uses java.nio.file.Files (not Gradle's fileTree/project.delete) so
the closure stays compatible with the configuration cache.



To unsubscribe from these emails, change your notification settings at https://github.com/PCGen/pcgen/settings/notifications