Bump pom-scijava from 38.0.1 to 40.0.0 (Fiji-Stable track)

[yzx9]

Bumps the plugin's parent POM org.scijava:pom-scijava from 38.0.1 to 40.0.0, aligning it with the Fiji-Stable track.

closes #115

Supersedes and closes #115 (Dependabot's proposal to jump straight to 44.0.0).

Why 40.0.0 and not the latest (44.0.0)?

The deciding factor is the Java baseline. The build floor is set by scijava.jvm.version in pom-scijava-base (the parent of pom-scijava), enforced via maven.compiler.release + requireJavaVersion:

pom-scijava	pom-scijava-base	scijava.jvm.version	Fiji track
38.0.1 (before)	19.0.0	8	—
40.0.0 (this PR)	21.1.0	8	Fiji-Stable (fiji/fiji master)
42.0.0	20.0.0	8	Fiji-Latest (fiji/fiji main)
44.0.0	22.0.0	11	—

• 40.0.0 stays on Java 8 — no change to the nix dev shell (flake.nix jdk8) or CI (.github/workflows/release.yml java-version: "8").
• 44.0.0 raises the floor to Java 11 (upstream commit "Update minimum Java version: 8 -> 11", also visible in Bump org.scijava:pom-scijava from 40.0.0 to 45.0.0 in /plugin #115's changelog). That would require bumping the build JDK across flake.nix and CI, and would drop Fiji-Stable runtime support (Java-11 bytecode can't load in a Java-8 Fiji).

Why the Fiji-Stable track?

CopilotJ's plugin runs inside Fiji, so it must match the distribution our users run. A Java-8 / Fiji-Stable build runs on both Fiji-Stable (Java 8 JRE) and Fiji-Latest (bundled Java 21 JRE) — the widest compatibility. fiji/fiji's master (the stable maintenance branch) currently parents to pom-scijava 40.0.0, so 40.0.0 matches what Fiji-Stable is built against.

The plugin has no direct net.imglib2.* imports (only net.imagej.*), so the imglib2 6 → 7 jump is low-risk for our source.

Verification

just build-plugin (mvn -f plugin/pom.xml clean package) → BUILD SUCCESS with pom-scijava 40.0.0. (Managed deps that moved: imglib2 6.3.0 → 7.1.5, imagej2 2.15.0 → 2.17.0, jackson 2.16.1 → 2.18.0. The first run hit transient Connection resets from maven.scijava.org while pulling the large sc.fiji:fiji aggregator tree; it succeeded on retry once artifacts cached in ~/.m2.)

How to check pom-scijava versions in the future

Recording the method so it's reproducible:

1. Which Fiji track a pom-scijava belongs to → fiji/fiji branches: master's <parent> = Fiji-Stable line; main's <parent> = Fiji-Latest line.

   curl -fsSL https://raw.githubusercontent.com/fiji/fiji/master/pom.xml | grep -A4 '<parent>'

2. Java floor of a given pom-scijava → read scijava.jvm.version from the pom-scijava-base version it parents to (pom-scijava's <parent> → pom-scijava-base X.Y.Z → its <scijava.jvm.version>):

   curl -fsSL https://raw.githubusercontent.com/scijava/pom-scijava-base/pom-scijava-base-22.0.0/pom.xml | grep scijava.jvm.version

3. What's actually deployed (can drift from the BOM) → the update site's db.xml.gz:
   • Fiji-Stable: https://sites.imagej.net/Java-8/db.xml.gz
   • Fiji-Latest: https://sites.imagej.net/Fiji/db.xml.gz
4. Latest released pom-scijava → Maven Central maven-metadata.xml or scijava/pom-scijava tags.

⚠️ Caveat: pom-scijava version numbers do not strictly track component freshness — e.g. 40.0.0 manages newer imglib2 (7.1.5) than 42.0.0 (7.1.2). Compare per-component managed versions, not the BOM number.

closes #115