pcgen-github — For GITHUB Commit messages

[Pcgen-github] [PCGen/pcgen] 4fa2b8: Build/test cleanup: drop duplicated test JVM args, ...

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

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

  Changed paths:
    M build.gradle
    M code/src/test/plugin/PluginBuildTest.java

  Log Message:
  -----------
  Build/test cleanup: drop duplicated test JVM args, refresh stale Javadoc (#7587)

* build.gradle: drop duplicated test-task JVM args

  tasks.named("test", Test) re-added six args that
  tasks.withType(Test).configureEach already applies to every Test:
  -Dtestfx.robot=glass, -Dtestfx.headless=true, -Dprism.order=sw,
  --add-exports for javafx.graphics/com.sun.javafx.util and
  javafx.base/com.sun.javafx.logging, and --add-opens for
  javafx.graphics/com.sun.glass.ui. Each was landing on the test JVM
  command line twice.

  Kept --add-opens javafx.graphics/com.sun.javafx.application: withType
  has --add-exports (not --add-opens) for that package, and TestFX's
  @AfterEach cleanup uses setAccessible(true) on a private field of
  ParametersImpl, which exports alone don't satisfy. Verified by running
  pcgen.gui3.dialog.AboutDialogTest after the cleanup.

* PluginBuildTest: refresh stale class Javadoc

  The class Javadoc still referenced the deleted Ant pluginbuild.xml.
  Now describes what the test actually does today: every plugin source
  file under code/src/java/plugin/<category>/ is packaged into the
  matching <category>plugins.jar produced by code/gradle/plugins.gradle.



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

[Pcgen-github] [PCGen/pcgen] 9cf92c: RollInfo: fix two round-trip bugs and tighten the ...

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

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

  Changed paths:
    M code/src/java/pcgen/core/Globals.java
    M code/src/java/pcgen/core/RollInfo.java
    M code/src/java/pcgen/core/term/EQDamageDiceTermEvaluator.java
    M code/src/java/pcgen/core/term/EQDamageDieTermEvaluator.java
    M code/src/test/pcgen/core/GlobalsTest.java
    A code/src/utest/pcgen/core/RollInfoTest.java

  Log Message:
  -----------
  RollInfo: fix two round-trip bugs and tighten the class (#7586)

* RollInfo: rewrite toString() keep-list rendering

The keep-list section used `while (keepList != null) // let break work`
with `break` as a goto-style label. The body never iterates — every
path either falls through or breaks. Extract it as a helper that returns
false on the malformed all-false case so toString() can bail.

* RollInfo: add copy constructor; collapse Globals.adjustDamage clone hack

Globals.adjustDamage cloned a RollInfo via a toString-then-reparse round
trip ("Ugh, have to do this for 'cloning' to avoid polluting the master")
and then mutated the clone's `times` field directly. The round trip is
both lossy (drift risk on toString/parse) and forces the field to stay
package-visible.

Add `RollInfo(RollInfo other, int timesMultiplier)` for explicit cloning
with a scale factor, and use it in Globals.adjustDamage.

* RollInfo: throw IllegalArgumentException on parse failure

Constructor previously logged the error and returned a zeroed object,
forcing every caller to re-check for "empty" RollInfo or trust unparseable
input. Now it throws, and the four direct callers handle the failure
explicitly:

- Globals.adjustDamage falls back to returning aDamage unchanged
- EQDamage{Dice,Die}TermEvaluator returns "0"

UpToken / DownToken already had IAE catch blocks (previously dead code);
they now actually fire on bad input.

Also clarifies the "Need to test for higher dice" comment in adjustDamage
and replaces a direct .sides field read with .getSides().

* RollInfo: tighten sides/times field access to private

The class is final and all reads now go through getSides() / getTimes()
or the copy constructor, so protected was misleading — it suggested a
subclass extension point that doesn't exist.

* RollInfo: add tests for parser, copy ctor, and adjustDamage fallback

- New RollInfoTest covers round-trip toString for the standard forms
  (NdM, modifiers, keep top/bottom/list, reroll bounds, total floor/ceiling),
  the copy constructor (incl. keepList cloning), validateRollString, and
  the IllegalArgumentException contract on bad input.
- GlobalsTest.testAdjustDamage gains two cases: NdM scaling via the 1dM
  step lookup, and the unparseable-input fall-through.
- RollInfo.parseRollInfo now also catches NoSuchElementException (raised
  by StringTokenizer on empty input) so the IAE contract is honoured.

* RollInfo: simplify toString helpers per Sonar feedback

- Merge the nested if at toString() / appendKeepList call site (S1066).
- Split appendKeepList into countKept / leadingKeptRun / trailingKeptRun
  helpers and emit the explicit list via IntStream + Collectors.joining
  (S3776: cognitive complexity 27 → under threshold).

* RollInfo: extract duplicated parser literals (Sonar S1192)

- "Bad roll parsing in '" → PARSE_ERROR_PREFIX
- "mM+-tT" → POST_SIDES_DELIMS (also reused in the initial "/\|mM+-tT"
  delimiter set)

* RollInfoTest: move to utest source set

The class has no Globals/GameMode/file-loader dependencies — it's a
pure unit test. Relocating from slowtest to utest puts it on every PR's
fast feedback loop and removes unnecessary JavaFX module-path overhead.

Pure rename, no content change.

* RollInfo: fix two round-trip bugs surfaced by tests

1. Parser ignored carefully-set parseChars in the modifier (+/-) and
   total-clamp (t/T) branches, calling nextToken(" ") and greedily eating
   the next clamp character. So '1d20+5t2' threw NumberFormatException on
   "5t2", and toString() could emit strings the parser refused — round-
   trip was broken for any modifier-then-clamp combo.

2. Copy constructor cloned keepList as-is even when timesMultiplier > 1.
   The cloned array was sized to the source's times, but this.times got
   scaled, so toString() walked past the end and threw
   ArrayIndexOutOfBoundsException. There's no canonical way to extend a
   keep-list across replicated dice groups, so scaling now drops it.

Regression tests added for both.

* RollInfoTest: parameterize round-trip, normalisation, and rejection cases

Collapse the per-notation round-trip tests, the bad-input rejection
tests, and a new validate-vs-constructor agreement check into
@ParameterizedTest blocks driven by @ValueSource and @CsvSource. Adds
coverage for the implicit-times-1 case (no leading number), keep-list
shape normalisation (|a,b -> /n or \n where contiguous), the
discontinuous-stays-explicit case, and the negative-sides rejection.

* RollInfo: correct constructor Javadoc to match parser

Two errors in the syntax doc:
1. m/M were described with their reroll fields swapped — the parser
   sets rerollBelow on 'm' and rerollAbove on 'M', not the reverse.
2. t/T described totalFloor/totalCeiling without saying they clamp the
   total in the named direction.

Also fixes typos ("postitive", "*integer").

* EQ damage evaluators: log unparseable damage instead of silently zeroing

The catches added when RollInfo started throwing IllegalArgumentException
were swallowing the original cause without trace. The old behaviour
(silent log + zeroed RollInfo) at least left a Logging.errorPrint
breadcrumb; the new catches threw that away.

Reinstate the diagnostic: log the offending equipment key and the
unparseable damage string before falling through to "0", so LST data
defects don't disappear into a silent zero.



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

[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

[Pcgen-github] [PCGen/pcgen] d3d8a1: build.gradle, reporting.gradle: small cleanups (#7...

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

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

  Changed paths:
    M build.gradle
    M code/gradle/reporting.gradle

  Log Message:
  -----------
  build.gradle, reporting.gradle: small cleanups (#7584)

* build.gradle: drop stray println debug statements

Four leftover debug printlns from earlier work, all firing in tasks
where Gradle's own logging already covers the same information. The
last one ("Args for for") also has a typo and fires once per JavaCompile
invocation, making it the loudest of the four.

* build.gradle: fix stale 'Developer build' header comment

'gradle' with no args runs the help task (default since Gradle 7), not
a developer build, since no defaultTasks is declared. Replace the
misleading line with 'gradle tasks' to point at the actual discovery
command.

* reporting.gradle: load Spotbugs Confidence via Class.forName, not findLoadedClass

ClassLoader.findLoadedClass returns null if the class hasn't already
been loaded by some other code path -- a race waiting to happen for
'reportLevel = SpotBugsConfidence.LOW'. Class.forName(name, true, loader)
actively triggers loading, so the lookup is deterministic.

A bare 'import com.github.spotbugs.snom.Confidence' won't work: this
file is applied via 'apply from:', so it's compiled before the
spotbugs plugin's classes are visible to it.

* build.gradle: keep compiler-args println (without the typo)

Restore the line dropped in 06c505789b for the JavaCompile configurator.
It prints the resolved --module-path / --add-modules / --add-exports
list per source set, which is genuinely useful when a JavaFX or
mods/lib path stops resolving. The other three printlns dropped in
that commit (copyToLibs, downloadJavaFXLocal, extractJavaFXLocal) stay
gone -- they were pure 'I'm here' markers that --info already covers.

Also fixes the original 'for for' typo.



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

[Pcgen-github] [PCGen/pcgen] 4589fa: build.gradle: fix clean/download race and merged-m...

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

  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

[Pcgen-github] [PCGen/pcgen] 56e4bd: Fix jpackage app crash on JDKs where jlink package...

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

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

  Changed paths:
    M build.gradle

  Log Message:
  -----------
  Fix jpackage app crash on JDKs where jlink package probe misses java.logging (#7581)

The org.beryx.jlink plugin's built-in package→module resolver (the default
`useJdeps = 'no'`) silently fails to find JDK modules on some distributions
— observed on Temurin 25/macOS, where the createMergedModule log shows
"Cannot find module exporting java.logging" (and java.io, java.lang, java.util,
…) for the JDK packages used by the merged jars.

The plugin proceeds anyway and emits a merged module-info that omits the
missing `requires` directives. At runtime freemarker's _JULLoggerFactory then
fails 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

…and PcGen.app dies before main() runs. SapMachine 25 happens to resolve the
JDK modules correctly, so the same build worked on some machines and not on
others.

Switch to `useJdeps = 'exclusively'`. The JDK's own jdeps tool ships with
every conforming JDK 9+ and reliably resolves modules across vendors. With
this setting the merged module-info contains `requires java.logging` (plus
java.sql, java.prefs, java.xml, java.desktop, jdk.jfr, jdk.unsupported,
jdk.xml.dom, java.compiler) regardless of which JDK is building the image,
and the packaged app launches cleanly.

Listing those JDK modules explicitly inside `mergedModule { … }` is not a
viable alternative: the plugin appends user-supplied `requires` verbatim after
the auto-derived ones with no dedup, so on JDKs where derivation succeeds the
javac compile of module-info would fail with duplicate-requires errors. With
`useJdeps = 'exclusively'` we keep just the SPI/reflection-loaded ones the
toolchain cannot derive (java.naming, java.scripting, java.management,
jdk.httpserver, jdk.unsupported.desktop).



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

[Pcgen-github] [PCGen/pcgen] 1805ae: Remove unused GMGen randomname i18n keys (#7582)

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

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

  Changed paths:
    M code/src/resources/pcgen/lang/LanguageBundle.properties
    M code/src/resources/pcgen/lang/LanguageBundle_es.properties
    M code/src/resources/pcgen/lang/LanguageBundle_fr.properties
    M code/src/resources/pcgen/lang/LanguageBundle_it.properties
    M code/src/testResources/pcgen/lang/cleaned.properties

  Log Message:
  -----------
  Remove unused GMGen randomname i18n keys (#7582)

`in_plugin_randomname_name` and `in_mn_plugin_randomname_name` were
referenced only from `plugin/doomsdaybook/RandomNamePlugin.java`, the
GMGen plugin wrapper that advertised the "Random Names" tab name and
mnemonic. PR #7566 deleted that wrapper as part of the Random-name
dialog Swing → JavaFX rewrite, and the live core dialog
(`RandomNameDialog` → `RandomNamePanelController` + `RandomNamePanel.fxml`)
doesn't expose a plugin-style tab label, so the keys have no replacement
in core.

Confirmed unused via `ScanForUnusedIl8nKeysTest` and a manual grep over
`*.java`, `*.fxml`, `*.lst`. Removed from the four locale bundles that
still carried them (en, es, fr, it; de/ja/pt already lacked them) and
regenerated the `cleaned.properties` snapshot the scanner produces.



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

[Pcgen-github] [PCGen/pcgen] eeebb3: TestHelper: load plugins via JUnit extension; clea...

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

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

  Changed paths:
    M .github/workflows/gradle-release-manual.yml
    M .github/workflows/gradle-release.yml
    M .github/workflows/gradle-test.yml
    M PCGen-Formula/build.gradle
    M PCGen-Formula/code/src/test/pcgen/base/testsupport/AbstractFormulaTestCase.java
    M PCGen-Formula/code/src/test/pcgen/base/testsupport/TestUtilities.java
    M build.gradle
    M code/src/itest/pcgen/cdom/facet/StatIntegrationTest.java
    M code/src/itest/pcgen/io/RaceTargetSaveRestoreTest.java
    M code/src/itest/plugin/lsttokens/datacontrol/SelectableTokenIntegrationTest.java
    M code/src/itest/plugin/lsttokens/editcontext/testsupport/AbstractBigDecimalIntegrationTestCase.java
    M code/src/itest/plugin/lsttokens/editcontext/testsupport/AbstractIntegerIntegrationTestCase.java
    M code/src/itest/tokencontent/GlobalModifyTest.java
    M code/src/java/pcgen/system/Main.java
    M code/src/test/pcgen/AbstractCharacterTestCase.java
    M code/src/test/pcgen/AbstractJunit5CharacterTestCase.java
    M code/src/test/pcgen/cdom/helper/AspectTest.java
    M code/src/test/pcgen/core/BonusManagerTest.java
    M code/src/test/pcgen/core/ChallengeRatingPathfinderTest.java
    M code/src/test/pcgen/core/EquipmentModifierTest.java
    M code/src/test/pcgen/core/PCClassTest.java
    M code/src/test/pcgen/core/PCTemplateTest.java
    M code/src/test/pcgen/core/PObjectTest.java
    M code/src/test/pcgen/core/PlayerCharacterSpellTest.java
    M code/src/test/pcgen/core/PrereqHandlerTest.java
    M code/src/test/pcgen/core/StatListTest.java
    M code/src/test/pcgen/core/analysis/SpellLevelTest.java
    M code/src/test/pcgen/core/levelability/AddClassSkillsTest.java
    M code/src/test/pcgen/core/prereq/PreAbilityTest.java
    M code/src/test/pcgen/core/prereq/PreAlignTest.java
    M code/src/test/pcgen/core/prereq/PreArmorProfTest.java
    M code/src/test/pcgen/core/prereq/PreArmorTypeTest.java
    M code/src/test/pcgen/core/prereq/PreAttTest.java
    M code/src/test/pcgen/core/prereq/PreBirthplaceTest.java
    M code/src/test/pcgen/core/prereq/PreCSkillTest.java
    M code/src/test/pcgen/core/prereq/PreCampaignTest.java
    M code/src/test/pcgen/core/prereq/PreCheckBaseTest.java
    M code/src/test/pcgen/core/prereq/PreCheckTest.java
    M code/src/test/pcgen/core/prereq/PreClassTest.java
    M code/src/test/pcgen/core/prereq/PreDRTest.java
    M code/src/test/pcgen/core/prereq/PreDeityAlignTest.java
    M code/src/test/pcgen/core/prereq/PreDeityDomainTest.java
    M code/src/test/pcgen/core/prereq/PreDeityTest.java
    M code/src/test/pcgen/core/prereq/PreDomainTest.java
    M code/src/test/pcgen/core/prereq/PreEquipPrimaryTest.java
    M code/src/test/pcgen/core/prereq/PreEquipSecondaryTest.java
    M code/src/test/pcgen/core/prereq/PreEquipTest.java
    M code/src/test/pcgen/core/prereq/PreEquipTwoWeaponTest.java
    M code/src/test/pcgen/core/prereq/PreGenderTest.java
    M code/src/test/pcgen/core/prereq/PreHDTest.java
    M code/src/test/pcgen/core/prereq/PreHPTest.java
    M code/src/test/pcgen/core/prereq/PreHandsTest.java
    M code/src/test/pcgen/core/prereq/PreItemTest.java
    M code/src/test/pcgen/core/prereq/PreKitTest.java
    M code/src/test/pcgen/core/prereq/PreLangTest.java
    M code/src/test/pcgen/core/prereq/PreLegsTest.java
    M code/src/test/pcgen/core/prereq/PreLevelMaxTest.java
    M code/src/test/pcgen/core/prereq/PrePCLevelTest.java
    M code/src/test/pcgen/core/prereq/PreRaceTest.java
    M code/src/test/pcgen/core/prereq/PreReqHandlerTest.java
    M code/src/test/pcgen/core/prereq/PreRuleTest.java
    M code/src/test/pcgen/core/prereq/PreShieldProfTest.java
    M code/src/test/pcgen/core/prereq/PreSizeTest.java
    M code/src/test/pcgen/core/prereq/PreSpellDescriptorTest.java
    M code/src/test/pcgen/core/prereq/PreSpellSubSchoolTest.java
    M code/src/test/pcgen/core/prereq/PreStatTest.java
    M code/src/test/pcgen/core/prereq/PreSubClassTest.java
    M code/src/test/pcgen/core/prereq/PreTemplateTest.java
    M code/src/test/pcgen/core/prereq/PreTypeTest.java
    M code/src/test/pcgen/core/prereq/PreVarTest.java
    M code/src/test/pcgen/core/term/EvaluatorFactoryTest.java
    M code/src/test/pcgen/core/term/PCRacialHDSizeTermEvaluatorTest.java
    M code/src/test/pcgen/gui2/facade/CharacterAbilitiesTest.java
    M code/src/test/pcgen/gui2/facade/CharacterFacadeImplTest.java
    M code/src/test/pcgen/gui2/facade/CompanionSupportFacadeImplTest.java
    M code/src/test/pcgen/gui2/facade/EquipmentSetFacadeImplTest.java
    M code/src/test/pcgen/gui2/facade/Gui2InfoFactoryTest.java
    M code/src/test/pcgen/gui2/facade/SpellBuilderFacadeImplTest.java
    M code/src/test/pcgen/io/PCGVer2ParserCharacterTest.java
    M code/src/test/pcgen/io/exporttoken/AbilityListTokenTest.java
    M code/src/test/pcgen/io/exporttoken/SpellMemTokenTest.java
    M code/src/test/pcgen/io/exporttoken/TextTokenTest.java
    M code/src/test/pcgen/io/exporttoken/VarTokenTest.java
    M code/src/test/pcgen/persistence/lst/DataLoadTest.java
    M code/src/test/pcgen/persistence/lst/DataTest.java
    M code/src/test/pcgen/persistence/lst/FeatTest.java
    M code/src/test/pcgen/persistence/lst/InstallLoaderTest.java
    M code/src/test/pcgen/persistence/lst/MigrationLoaderTest.java
    M code/src/test/pcgen/persistence/lst/PObjectLoaderTest.java
    M code/src/test/pcgen/persistence/lst/output/prereq/PrerequisiteWriterTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreCheckParserTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreEquipTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreItemTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreKitParserTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreLanguageParserTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreMoveParserTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreMultParserTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreParserFactoryTest.java
    M code/src/test/pcgen/persistence/lst/prereq/PreStatParserTest.java
    M code/src/test/pcgen/util/TestHelper.java
    M code/src/test/plugin/exporttokens/AttackTokenTest.java
    M code/src/test/plugin/exporttokens/CampaignHistoryTokenTest.java
    M code/src/test/plugin/exporttokens/SkillSitTokenTest.java
    M code/src/test/plugin/exporttokens/SkillTokenTest.java
    M code/src/test/plugin/exporttokens/SpellListTokenTest.java
    M code/src/test/plugin/jepcommands/CountCommandTest.java
    M code/src/test/plugin/jepcommands/CountDistinctCommandTest.java
    A code/src/testcommon/pcgen/test/PCGenTestEnvironment.java
    M code/src/utest/pcgen/cdom/base/FormulaFactoryTest.java
    M code/src/utest/pcgen/persistence/RecursiveFileFinderTest.java
    M code/src/utest/plugin/lsttokens/FollowersLstTest.java
    M code/src/utest/plugin/lsttokens/VisionLstTest.java

  Log Message:
  -----------
  TestHelper: load plugins via JUnit extension; cleanup (#7580)

* TestHelper: load plugins via static initializer

`TestHelper.loadPlugins()` was already idempotent — a `boolean loaded`
flag guarded the expensive `Main.createLoadPluginTask().run()` call so
only the first invocation did real work. The remaining cleanup turns
that runtime guard into a structural one:

* Replace the mutable `boolean loaded` field + `if (!loaded)` branch
  with a private static initializer. Plugin loading now runs exactly
  once when `TestHelper` is first class-loaded, enforced by the JVM
  rather than by a flag check that future maintainers could bypass.
* Drop the two internal `loadPlugins()` calls in `makeEquipment` and
  `makeAbilityFromString` — they're inside the same class that defines
  the no-op, so by the time the JVM is executing those methods the
  static initializer has already run.
* Keep the no-op `loadPlugins()` method and the 12 external call sites.
  In most callers `loadPlugins()` is the only `TestHelper` reference, so
  removing it would let unused-import cleanup strip `import TestHelper`,
  which would in turn prevent class-loading and skip the static
  initializer. The "redundant" calls are load-bearing: they keep
  `TestHelper` on each test's class-load graph.
* Add an inline comment to silence SonarQube S1186 ("Methods should not
  be empty") and to record the load-bearing rationale in-place.

* TestHelper: clean up IDE-flagged warnings

- Remove unused imports (BufferedReader, FileInputStream,
  InputStreamReader, PersistenceLayerException)
- Drop unthrown 'throws PersistenceLayerException' from parsePCClassText
- Parameterize Class<?> in createSource
- Replace string-based "Object".equals(clazz.getName()) walk-stop with
  identity compare clazz != Object.class
- Inline redundant pccFilesPath local in findDataFolder
- Switch three concatenated LOG.info calls to parameterized LOG.log
- Fill in missing @param entries on hasWeaponProfKeyed

* Replace local parsePCClassText copies with TestHelper.parsePCClassText

PCClassTest and AddClassSkillsTest each carried a private duplicate of
the same parsePCClassText helper, declared with an unthrown
PersistenceLayerException. Now that the canonical helper in TestHelper
has had its stale throws removed, the local copies are pure dead code
and the AddClassSkillsTest try/catch was already unreachable.

* TestHelper: drop dead methods makeAbilityFromString, makeWeaponProf, loadGameModes

None of the three are referenced anywhere in the repo (no callers, no
reflective lookups). Removing them also lets us drop the unused abLoader
and source fields plus six imports they pulled in (AbilityLoader,
CampaignFileLoader, ConfigurationSettings, PCGenTask,
PropertyContextFactory, SystemUtils).

* ci: add --stacktrace --info to test runs to debug datatest crash

* TestFX: use --add-opens for ParametersImpl on JavaFX 25

TestFX's ApplicationExtension.afterEach calls cleanupParameters, which
does setAccessible(true) on the private static ParametersImpl.params
field — deep reflection that --add-exports doesn't grant. Pre-Java 25
this slipped through; on JavaFX 25 it throws InaccessibleObjectException
("module javafx.graphics does not opens com.sun.javafx.application to
unnamed module") and crashes the test JVM, which surfaces downstream as
"non-zero exit value 1" with no test failures reported.

Replace --add-exports with --add-opens for that single package; the rest
of the JVM-arg block is correct.

Also revert the temporary --stacktrace --info debug flags from the test
workflow (they were a one-shot diagnostic, not a permanent setting; they
balloon the CI log to ~100k lines).

* ci: temporarily add --stacktrace --info to expose datatest startup crash

* ci: revert temporary --stacktrace --info — diagnosis done

* Main: extract runBootstrapTasks() to capture canonical init order

The plugin/game-mode/campaign loader sequence was duplicated verbatim
in startupWithGUI() and startupWithoutGUI(). Pull it into a single
package-private helper so test code can run the same sequence and
the order can never drift between the two callers.

Behaviour-preserving refactor; no production changes.

* Add PCGenTestEnvironment JUnit 5 extension

Loads PCGen plugins exactly once per JVM via a BeforeAllCallback,
keyed on ExtensionContext.Store.GLOBAL so the work happens at most
once across the whole test JVM. Auto-discovered via
META-INF/services and the autodetection.enabled property, so test
classes don't need any annotation to opt in.

This is the proper replacement for the static initializer the
previous commit introduced: BeforeAllCallback fires after JUnit's
lifecycle is set up but before any user @BeforeAll runs, so it
no longer perturbs the init order that DataTest/DataLoadTest
require.

* TestHelper: remove static initializer; mark loadPlugins() deprecated

The static initializer ran Main.createLoadPluginTask() at class-load
time — earlier than DataTest/DataLoadTest's expected init order, which
caused Main.loadProperties() to find no settings file and call
GracefulExit.exit(1), tearing down the test JVM with no stack trace.

PCGenTestEnvironment (added in the previous commit) now owns plugin
loading, runs at the correct point in the JUnit lifecycle, and is
auto-discovered for every test class.

Keep loadPlugins() as a deprecated no-op so existing call sites keep
compiling — they can be cleaned up incrementally rather than all in
one go.

* DataTest/DataLoadTest: use Main.runBootstrapTasks() for init order

The two loadGameModes() helpers each open-coded the same 4-step
sequence (createLoadPluginTask + GameModeFileLoader + CampaignFileLoader,
each constructed and run individually). Replace with the runBootstrapTasks()
helper extracted in the earlier commit, so all three call sites
(production GUI, production headless, test) share one definition of
the canonical bootstrap order.

Make runBootstrapTasks public — it's the same visibility the existing
loadProperties() and createLoadPluginTask() helpers already have.

* PCGenTestEnvironment: opt-in via @ExtendWith, not auto-discovery

Auto-discovery via META-INF/services would force plugin loading on
EVERY test class in the JVM, including ones that explicitly assume
plugins are NOT loaded. Concrete example: SetSolverManagerTest.setUp
constructs a fresh VariableContext and calls addFunction(getOther),
which fails with 'Cannot load two functions of name: getOther' if
PluginFunctionLibrary already has it (plugin loading populates that
singleton, and VariableContext's constructor copies all entries from
it).

Make plugin loading opt-in: @ExtendWith(PCGenTestEnvironment.class)
on classes that need it. Apply to AbstractCharacterTestCase and
AbstractJunit5CharacterTestCase (lifts ~114 subclasses) plus the
10 standalone test classes that previously called loadPlugins()
explicitly. Drop the META-INF/services + junit-platform.properties
files.

* TestHelper: delete deprecated loadPlugins() no-op

No call sites remain in the tree. The previous commit kept it as a
deprecated shim only to avoid touching every test class in one go;
that's now done. Drop it.

* ci: enable --stacktrace on every gradlew invocation

Costs nothing on green builds (only fires on failure), saves a
diagnostic round-trip when CI fails for a non-obvious reason. This
session needed two separate diagnostic commits (one for the
TestFX/JavaFX 25 InaccessibleObjectException and one for the
TestHelper static-initializer-induced JVM exit) precisely because
neither failure showed a stack trace by default — Gradle just said
'non-zero exit value 1' and pointed at --stacktrace as the next
step. Make that the next step happen automatically.

* JUnit 6 cleanup: replace deprecated APIs in test scaffolding

ExtensionContext.Store#getOrComputeIfAbsent was deprecated in JUnit 6.0
in favor of #computeIfAbsent (mirrors java.util.Map). Three other files
still imported junit.framework.TestCase / org.junit.Test from JUnit 3/4
even though the rest of their bodies were already on Jupiter.

PCGenTestEnvironment switches to computeIfAbsent. AbstractFormulaTestCase
and TestUtilities drop junit.framework.TestCase.fail in favor of Jupiter
Assertions.fail. RecursiveFileFinderTest swaps org.junit.Test for the
Jupiter @Test.

* JUnit 6 migration: rewrite org.junit.Assert to Jupiter Assertions

JUnit 6 drops junit:junit from the classpath, so the org.junit.Assert
static helpers used by 86 test files no longer resolve. Each file now
imports the equivalent from org.junit.jupiter.api.Assertions.

Jupiter reverses the message argument convention: JUnit 4's
assertEquals(message, expected, actual) becomes
assertEquals(expected, actual, message). Mass-applying the import swap
alone would silently match Jupiter's assertEquals(Object, Object, String)
overload with `message` read as `expected` and vice versa - the calls
would compile but every failure message would be wrong. The 1054
swap-able call sites (assertEquals/assertTrue/assertFalse/assertNull/
assertNotNull/assertSame/assertArrayEquals with leading String literal)
are reordered to match Jupiter's convention. Nine sites where the
leading message was a String concatenation expression rather than a
literal were caught by the compiler and fixed by hand.

* Drop JUnit 4 / vintage engine from test classpath

With every test file now on Jupiter, neither the junit:junit jar nor the
junit-vintage-engine runner is needed. The stale comment claiming "~870
legacy tests" is removed - the actual count was zero by the time the
migration finished.



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

[Pcgen-github] [PCGen/pcgen] 92bbe1: Defer Adoptium API call until a JavaFX download ta...

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

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

  Changed paths:
    M build.gradle

  Log Message:
  -----------
  Defer Adoptium API call until a JavaFX download task needs it (#7579)

`latestJavaVersion` was eagerly invoked on every Gradle invocation
(`}(javaVersion)`), making each `./gradlew <anything>` round-trip to
api.adoptium.net even for `help`, `tasks`, or any local-only target.

Convert it to a memoized closure consumed at use sites that already sit
inside lazy `tasks.register(...)` bodies (`downloadJfxMods`,
`downloadJavaFXLocal`). The network call now fires at most once per
build, and only when one of those JavaFX download tasks is realized.

Closes OPTIMIZATION.md item #2.



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

[Pcgen-github] [PCGen/pcgen] bd5f4e: Drop Built-Date, Built-JDK, Created-By from plugin...

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

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

  Changed paths:
    M code/gradle/plugins.gradle

  Log Message:
  -----------
  Drop Built-Date, Built-JDK, Created-By from plugin manifests (#7578)

`new Date()` was evaluated at configuration time on every Gradle
invocation, so each plugin jar's manifest embedded the build wall-clock.
That made the jars non-deterministic byte-for-byte across builds and
broke Gradle's configuration cache for plugin tasks.

The companion `Built-JDK` and `Created-By` attributes were dropped at
the same time because:

1. Nothing in the codebase reads any of these three attributes
   (`grep -rn 'Built-Date|Built-JDK|Created-By'` returns only the writer
   line). They were inert metadata.
2. The main `pcgen.jar` manifest does not carry equivalents, so the
   plugin jars were the odd ones out.
3. Real reproducibility would also require pinning archive timestamps
   (`preserveFileTimestamps = false`), file ordering
   (`reproducibleFileOrder = true`), and the JDK/Gradle versions across
   environments — for *all* archive tasks in the project, not just the
   plugin jars. Keeping `Built-JDK`/`Created-By` on plugin jars only
   would be inconsistent: it would leak environment info from a subset
   of artifacts without buying real reproducibility. If a future PR
   pursues full reproducible builds, it can apply those settings
   project-wide and re-introduce diagnostic attributes uniformly.

Verified: two clean builds of `:jarExportPlugins` now produce
byte-identical jars; configuration cache stores successfully for
`:jarAllPlugins`.



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

[Pcgen-github] [PCGen/pcgen] 1dc4cd: Drop spring-web dependency, replace HtmlUtils with...

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

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

  Changed paths:
    M build.gradle
    M code/src/java/module-info.java
    M code/src/java/pcgen/cdom/helper/AllowUtilities.java
    A code/src/utest/pcgen/cdom/helper/AllowUtilitiesTest.java

  Log Message:
  -----------
  Drop spring-web dependency, replace HtmlUtils with local helper (#7577)

spring-web was used in exactly one place: HtmlUtils.htmlEscape in
AllowUtilities.getAllowInfo. Removing it shrinks the runtime classpath
and the desktop-app dep tree (Spring Framework in a desktop app is
optimization item #24).

Changes:
- build.gradle: drop spring-web; introduce spring-framework-bom so
  spring-beans/spring-core are version-aligned (BOM groundwork from
  optimization item #4).
- module-info.java: remove `requires spring.web`.
- AllowUtilities: add a private htmlEscape that escapes only `&` and
  `<`, the only chars that can change HTML structure in element
  content. `>`, `"`, `'` are deliberately left alone — `>` is harmless
  in element content, and `"`/`'` only matter inside attribute values
  (this output is element content, never an attribute).

An audit of all INFO: token values across the bundled LST data
(~14k entries in 6.3k files) found zero occurrences of `<` or `>`
and only PCGen's own &nl; macro for `&`, so in practice the escape is
defensive: it protects against future content authors who introduce
literal `&` or `<` in INFO: text.

Unit tests added in AllowUtilitiesTest covering each escaped/unescaped
metacharacter, empty input, plain text, and unicode.



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

[Pcgen-github] [PCGen/pcgen] c4cbc4: fix: address CodeQL findings (zip-slip + implicit ...

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

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

  Changed paths:
    M code/src/java/pcgen/core/analysis/SkillModifier.java
    M code/src/java/pcgen/gui2/dialog/DataInstaller.java
    A code/src/utest/pcgen/gui2/dialog/DataInstallerZipSlipTest.java

  Log Message:
  -----------
  fix: address CodeQL findings (zip-slip + implicit narrowing) (#7576)

* DataInstaller: reject archive entries that escape the install dir

CodeQL java/zipslip flagged populateFileAndDirLists at lines 750/753;
the actual sink is createFiles at line 619 (FileOutputStream) and
createDirectories at line 617 (mkdirs), reached via a string-concat
correctFileName that didn't normalise '..' segments.

correctFileName now resolves each entry against its base directory and
rejects any path whose canonical form leaves that base. Both
canonicalisations happen on the resolved File, so symlinks, '.' and
'..' segments are all collapsed before comparison. The two callers
that didn't already throw IOException (checkOverwriteOK and
createDirectories) catch and abort the install with the existing
error-dialog pattern.

A hostile data set containing 'data/../../etc/whatever' would now be
refused before any file is written.

* SkillModifier: make double-to-int truncation explicit

CodeQL java/implicit-cast-in-compound-assignment flagged 12 sites in
this file where a 'double' bonus was accumulated into an 'int' via +=,
which silently inserts (int) at every addition. The intent was always
truncating accumulation -- the function returns Integer and uses
.intValue() for the formula path -- so the warning is purely about
making the cast visible.

Fix: write the cast at every site. No behaviour change; the bytecode
already contained the same i2d/d2i pair.

* DataInstaller: regression test for zip-slip rejection

Reflective unit test so the same class compiles against both the
pre-fix (`private`, no checked exception) and post-fix
(package-private, throws IOException) signatures of correctFileName.
Verified by hand: temporarily reverting DataInstaller to master and
re-running this test yields 1 pass + 2 failures (both '..'-escape
cases are silently accepted under the old logic), and restoring the
fix flips it to 3 passes -- which makes the test a real regression
guard rather than a tautology.

correctFileName goes from `private` to package-private to give the
test in the same package direct access; reflection was needed only
for the cross-state run.



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

[Pcgen-github] [PCGen/pcgen] 561a8b: ci: collapse 5 sequential gradle invocations into ...

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

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

  Changed paths:
    M .github/workflows/gradle-release-manual.yml
    M .github/workflows/gradle-release.yml

  Log Message:
  -----------
  ci: collapse 5 sequential gradle invocations into 1 (#7575)

* namegen: faster weighted picks and simpler DataValue sub-values

- NameList/RuleSet: precompute a cumulative-weight array at
  construction so pick() is O(log n) via binarySearch instead of two
  linear passes. Zero-weight entries are filtered into a parallel
  positives array, which keeps binarySearch correct when duplicates
  would otherwise let it land on a zero-weight index. Both records
  become final classes since cached state can't live on a record.
- DataValue: drop the hand-rolled DataSubValue linked list in favour
  of a lazily-allocated LinkedHashMap. putIfAbsent preserves the
  first-write-wins semantics the old recursive get() relied on.
- NameGenLazyData.gendersForRuleset: read directly from the ruleset's
  RuleSetMeta.categoryTitles() instead of scanning every Sex: bucket.
- NameGenerator.assemble: defer meaning/pronunciation StringBuilder
  allocation until a part actually overrides one, seeding from the
  name built so far. Avoids two builders' worth of churn on the
  common path where no part has sub-values.

* jlink: drop explicit requires that jlink already auto-derives

The jlink plugin's `additive = true` mode emits both the auto-derived
and the user-listed `requires` blocks without dedup. asm 9.10 (pulled
in by jlink 4.0.1) parses Java 25 class files that 9.9.1 silently
skipped, growing the auto-derived set enough to collide with our
explicit list and breaking `createMergedModule` with duplicate-requires
errors. Bump to 4.0.2 and keep only the modules the scanner can't
infer on its own.

* namegen: javadoc the childElements helpers

Brief description of each overload's contract (direct Element children,
optional tag-name filter) so future readers don't have to re-derive it
from the stream pipeline.

* release: run fullJpackage on Windows too

Drop the Os.FAMILY_MAC || Os.FAMILY_UNIX predicate that excluded
Windows from fullJpackage. The carve-out dates from when Windows
shipped via NSIS (`buildNsis`); that path was retired in be48763530
but the release-side hookup to invoke jpackage on Windows was never
added, leaving Windows release artifacts as the runtime zip only.

* release: produce native installers, not just runtime images

fullJpackage was wired to assembleJpackageImage (Mac: patchMacJpackage),
not the jpackage installer task — so each release shipped only the
jlinkZip runtime image, never a .dmg/.deb/.exe. Make jpackage depend on
the data-bundling step so it packages an image that already contains
data/plugins/preview/outputsheets, then point fullJpackage at jpackage.

Pin one installerType per OS (dmg / deb / exe) — without it jpackage
emits both formats per platform, doubling build time and (on Linux)
requiring rpmbuild that isn't installed on the Ubuntu runner.
Add --win-shortcut / --win-menu so the .exe creates Start-menu and
desktop entries; the existing --linux-shortcut and Mac-specific opts
were already in place. WiX 3.14 needed for the .exe is preinstalled
on the windows-latest runner.

* release: add portable zip alongside the native installer

Same self-contained app the installer ships, but as an unzip-and-run
archive — useful for users who don't want to run an installer (USB sticks,
locked-down environments, etc.). Per-platform: pcgen-<version>-<os>-<arch>-portable.zip.

The zip captures whatever fullJpackage left in build/jpackage/PcGen[.app],
so it includes data/plugins/preview/outputsheets and (on Mac) the patched
Info.plist + MacDirLauncher.

* release: include .deb in artifact upload glob

jpackage names Debian packages pcgen_<version>_<arch>.deb (underscore),
which the existing pcgen-*.* glob (hyphen) misses. Linux release runs
were uploading everything except the .deb. Add a second include for
the underscore form. .rpm uses pcgen-<version>.<arch>.rpm so it was
already covered.

* release: stop publishing image-*.zip and SHA-256 digest files

The image-*.zip artifacts (output of jlinkZip) are a JVM runtime image,
not a runnable PcGen — no launcher, no /data, /plugins, /preview, or
/outputsheets. Users who tried to run them got the "missing required
folders" dialog. Now that fullJpackage produces real installers and a
portable zip with the same .app the installer ships, image-*.zip is
just a confusing leftover. Drop it from the release upload (autobuild
keeps it via buildDist).

The SHA256-digests-*.txt files are also redundant: GitHub computes a
SHA-256 for every release asset automatically and exposes it via the
API. Anyone verifying integrity can shasum the file locally.

* ci: collapse 5 sequential gradle invocations into 1

Each ./gradlew invocation pays ~5-10s of configuration overhead and
~2-3s of daemon startup, plus a fresh task-graph build. The release
workflows ran 5 of them in series:

  ./gradlew clean build           # `clean` does nothing on a fresh runner
  ./gradlew compileSlowtest datatest pfinttest
  ./gradlew allReports            # = checkstyleMain + pmdMain + spotbugsMain,
                                  #   all already executed by `build`
  ./gradlew buildDist             # already a transitive dep of pcgenRelease
  ./gradlew pcgenRelease

Collapse to one invocation, drop the redundant `clean` and `allReports`,
and drop `buildDist` (which pcgenRelease already depends on transitively
via assembleArtifacts → jlinkZip).

Also set fail-fast: false on the matrix so a transient runner preemption
(seen on the partner-supplied ubuntu-24.04-arm image) doesn't kill the
other three OS jobs.



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

[Pcgen-github] [PCGen/pcgen] ba97fb: jlink 4.0.2 + native installers + namegen cleanup ...

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

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

  Changed paths:
    M build.gradle
    M code/gradle/release.gradle
    R code/src/java/pcgen/core/namegen/DataSubValue.java
    M code/src/java/pcgen/core/namegen/DataValue.java
    M code/src/java/pcgen/core/namegen/NameGenDataLoader.java
    M code/src/java/pcgen/core/namegen/NameGenLazyData.java
    M code/src/java/pcgen/core/namegen/NameGenerator.java
    M code/src/java/pcgen/core/namegen/NameList.java
    M code/src/java/pcgen/core/namegen/RuleSet.java

  Log Message:
  -----------
  jlink 4.0.2 + native installers + namegen cleanup (#7568)

* namegen: faster weighted picks and simpler DataValue sub-values

- NameList/RuleSet: precompute a cumulative-weight array at
  construction so pick() is O(log n) via binarySearch instead of two
  linear passes. Zero-weight entries are filtered into a parallel
  positives array, which keeps binarySearch correct when duplicates
  would otherwise let it land on a zero-weight index. Both records
  become final classes since cached state can't live on a record.
- DataValue: drop the hand-rolled DataSubValue linked list in favour
  of a lazily-allocated LinkedHashMap. putIfAbsent preserves the
  first-write-wins semantics the old recursive get() relied on.
- NameGenLazyData.gendersForRuleset: read directly from the ruleset's
  RuleSetMeta.categoryTitles() instead of scanning every Sex: bucket.
- NameGenerator.assemble: defer meaning/pronunciation StringBuilder
  allocation until a part actually overrides one, seeding from the
  name built so far. Avoids two builders' worth of churn on the
  common path where no part has sub-values.

* jlink: drop explicit requires that jlink already auto-derives

The jlink plugin's `additive = true` mode emits both the auto-derived
and the user-listed `requires` blocks without dedup. asm 9.10 (pulled
in by jlink 4.0.1) parses Java 25 class files that 9.9.1 silently
skipped, growing the auto-derived set enough to collide with our
explicit list and breaking `createMergedModule` with duplicate-requires
errors. Bump to 4.0.2 and keep only the modules the scanner can't
infer on its own.

* namegen: javadoc the childElements helpers

Brief description of each overload's contract (direct Element children,
optional tag-name filter) so future readers don't have to re-derive it
from the stream pipeline.

* release: run fullJpackage on Windows too

Drop the Os.FAMILY_MAC || Os.FAMILY_UNIX predicate that excluded
Windows from fullJpackage. The carve-out dates from when Windows
shipped via NSIS (`buildNsis`); that path was retired in be48763530
but the release-side hookup to invoke jpackage on Windows was never
added, leaving Windows release artifacts as the runtime zip only.

* release: produce native installers, not just runtime images

fullJpackage was wired to assembleJpackageImage (Mac: patchMacJpackage),
not the jpackage installer task — so each release shipped only the
jlinkZip runtime image, never a .dmg/.deb/.exe. Make jpackage depend on
the data-bundling step so it packages an image that already contains
data/plugins/preview/outputsheets, then point fullJpackage at jpackage.

Pin one installerType per OS (dmg / deb / exe) — without it jpackage
emits both formats per platform, doubling build time and (on Linux)
requiring rpmbuild that isn't installed on the Ubuntu runner.
Add --win-shortcut / --win-menu so the .exe creates Start-menu and
desktop entries; the existing --linux-shortcut and Mac-specific opts
were already in place. WiX 3.14 needed for the .exe is preinstalled
on the windows-latest runner.

* release: add portable zip alongside the native installer

Same self-contained app the installer ships, but as an unzip-and-run
archive — useful for users who don't want to run an installer (USB sticks,
locked-down environments, etc.). Per-platform: pcgen-<version>-<os>-<arch>-portable.zip.

The zip captures whatever fullJpackage left in build/jpackage/PcGen[.app],
so it includes data/plugins/preview/outputsheets and (on Mac) the patched
Info.plist + MacDirLauncher.

* release: include .deb in artifact upload glob

jpackage names Debian packages pcgen_<version>_<arch>.deb (underscore),
which the existing pcgen-*.* glob (hyphen) misses. Linux release runs
were uploading everything except the .deb. Add a second include for
the underscore form. .rpm uses pcgen-<version>.<arch>.rpm so it was
already covered.

* release: stop publishing image-*.zip and SHA-256 digest files

The image-*.zip artifacts (output of jlinkZip) are a JVM runtime image,
not a runnable PcGen — no launcher, no /data, /plugins, /preview, or
/outputsheets. Users who tried to run them got the "missing required
folders" dialog. Now that fullJpackage produces real installers and a
portable zip with the same .app the installer ships, image-*.zip is
just a confusing leftover. Drop it from the release upload (autobuild
keeps it via buildDist).

The SHA256-digests-*.txt files are also redundant: GitHub computes a
SHA-256 for every release asset automatically and exposes it via the
API. Anyone verifying integrity can shasum the file locally.



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

[Pcgen-github] [PCGen/pcgen]

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/dependabot/gradle/org.beryx.jlink-4.0.2
  Home:   https://github.com/PCGen/pcgen

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

[Pcgen-github] [PCGen/pcgen] 0b1fcd: Bump org.beryx.jlink from 4.0.1 to 4.0.2 (#7574)

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/PCGen/pcgen
  Commit: 0b1fcd501113c65e0896bf67f9e3a958db8093a6
      https://github.com/PCGen/pcgen/commit/0b1fcd501113c65e0896bf67f9e3a958db8093a6
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2026-06-03 (Wed, 03 Jun 2026)

  Changed paths:
    M build.gradle

  Log Message:
  -----------
  Bump org.beryx.jlink from 4.0.1 to 4.0.2 (#7574)

Bumps org.beryx.jlink from 4.0.1 to 4.0.2.

---
updated-dependencies:
- dependency-name: org.beryx.jlink
  dependency-version: 4.0.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <su...@gi...>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>



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

[Pcgen-github] [PCGen/pcgen]

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/dependabot/gradle/org.xmlunit-xmlunit-matchers-2.12.0
  Home:   https://github.com/PCGen/pcgen

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

[Pcgen-github] [PCGen/pcgen] 0e083f: Bump org.xmlunit:xmlunit-matchers from 2.11.0 to 2...

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/PCGen/pcgen
  Commit: 0e083fbcf494307df079d5b78be72b37ea31f89f
      https://github.com/PCGen/pcgen/commit/0e083fbcf494307df079d5b78be72b37ea31f89f
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2026-06-03 (Wed, 03 Jun 2026)

  Changed paths:

  Log Message:
  -----------
  Bump org.xmlunit:xmlunit-matchers from 2.11.0 to 2.12.0 (#7570)

Bumps [org.xmlunit:xmlunit-matchers](https://github.com/xmlunit/xmlunit) from 2.11.0 to 2.12.0.
- [Release notes](https://github.com/xmlunit/xmlunit/releases)
- [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md)
- [Commits](https://github.com/xmlunit/xmlunit/compare/v2.11.0...v2.12.0)

---
updated-dependencies:
- dependency-name: org.xmlunit:xmlunit-matchers
  dependency-version: 2.12.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <su...@gi...>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>



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

[Pcgen-github] [PCGen/pcgen]

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/dependabot/gradle/org.xmlunit-xmlunit-core-2.12.0
  Home:   https://github.com/PCGen/pcgen

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

[Pcgen-github] [PCGen/pcgen]

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/dependabot/gradle/net.sourceforge.pmd-pmd-java-7.25.0
  Home:   https://github.com/PCGen/pcgen

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

[Pcgen-github] [PCGen/pcgen] dfaf16: Bump org.xmlunit:xmlunit-core from 2.11.0 to 2.12....

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/PCGen/pcgen
  Commit: dfaf168a118fb5efb0ae0a2a5cfb786134f1ead0
      https://github.com/PCGen/pcgen/commit/dfaf168a118fb5efb0ae0a2a5cfb786134f1ead0
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2026-06-03 (Wed, 03 Jun 2026)

  Changed paths:
    M build.gradle

  Log Message:
  -----------
  Bump org.xmlunit:xmlunit-core from 2.11.0 to 2.12.0 (#7572)

Bumps [org.xmlunit:xmlunit-core](https://github.com/xmlunit/xmlunit) from 2.11.0 to 2.12.0.
- [Release notes](https://github.com/xmlunit/xmlunit/releases)
- [Changelog](https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md)
- [Commits](https://github.com/xmlunit/xmlunit/compare/v2.11.0...v2.12.0)

---
updated-dependencies:
- dependency-name: org.xmlunit:xmlunit-core
  dependency-version: 2.12.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <su...@gi...>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>



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

[Pcgen-github] [PCGen/pcgen] c836cd: Bump net.sourceforge.pmd:pmd-java from 7.24.0 to 7...

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/PCGen/pcgen
  Commit: c836cdf3d2f2aa1a3fc261402666a100f25175ff
      https://github.com/PCGen/pcgen/commit/c836cdf3d2f2aa1a3fc261402666a100f25175ff
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2026-06-03 (Wed, 03 Jun 2026)

  Changed paths:

  Log Message:
  -----------
  Bump net.sourceforge.pmd:pmd-java from 7.24.0 to 7.25.0 (#7573)

Bumps [net.sourceforge.pmd:pmd-java](https://github.com/pmd/pmd) from 7.24.0 to 7.25.0.
- [Release notes](https://github.com/pmd/pmd/releases)
- [Commits](https://github.com/pmd/pmd/compare/pmd_releases/7.24.0...pmd_releases/7.25.0)

---
updated-dependencies:
- dependency-name: net.sourceforge.pmd:pmd-java
  dependency-version: 7.25.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <su...@gi...>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>



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

[Pcgen-github] [PCGen/pcgen]

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/dependabot/gradle/net.sourceforge.pmd-pmd-ant-7.25.0
  Home:   https://github.com/PCGen/pcgen

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

[Pcgen-github] [PCGen/pcgen] 94ea37: Bump net.sourceforge.pmd:pmd-ant from 7.24.0 to 7....

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/PCGen/pcgen
  Commit: 94ea371b44cf46ed9d3d7d7989f31831daa5715f
      https://github.com/PCGen/pcgen/commit/94ea371b44cf46ed9d3d7d7989f31831daa5715f
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2026-06-03 (Wed, 03 Jun 2026)

  Changed paths:
    M build.gradle

  Log Message:
  -----------
  Bump net.sourceforge.pmd:pmd-ant from 7.24.0 to 7.25.0 (#7571)

Bumps [net.sourceforge.pmd:pmd-ant](https://github.com/pmd/pmd) from 7.24.0 to 7.25.0.
- [Release notes](https://github.com/pmd/pmd/releases)
- [Commits](https://github.com/pmd/pmd/compare/pmd_releases/7.24.0...pmd_releases/7.25.0)

---
updated-dependencies:
- dependency-name: net.sourceforge.pmd:pmd-ant
  dependency-version: 7.25.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <su...@gi...>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>



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

[Pcgen-github] [PCGen/pcgen]

[dependabot[bot] <no...@gi...>]

  Branch: refs/heads/dependabot/gradle/net.sf.saxon-Saxon-HE-13.0
  Home:   https://github.com/PCGen/pcgen

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