Publish a Java 11 main artifact and a jdk21 classifier

[ghedwards]

Both modules now emit two jars from one source tree:

Artifact	Class file	Runs on
cfml.parsing-VERSION.jar	55 (Java 11)	11, 17, 21, 25
cfml.parsing-VERSION-jdk21.jar	65 (Java 21)	21+

Same for cfml.dictionary. The default is the one that works everywhere; the classifier is there for consumers who specifically want a 21-targeted build.

Nothing in the source required 21

Both modules compile clean at --release 11 — which checks the API surface, not just the language level, so it would catch a Java 12+ method call as well as a language feature. And no runtime dependency is above class file 55:

$ for each jar on CFLint's runtime classpath: report class file major > 55
  cfml.dictionary-2.16.1-SNAPSHOT.jar   major=65
  cfml.parsing-2.16.1-SNAPSHOT.jar      major=65
  (36 jars checked, nothing else)

The only Java 21 artifacts in the whole downstream classpath were cfparser's own. The baseline was raised in 5d21f6c, whose message states it broke Java 11 and 17 consumers. This restores them without giving up a 21 build.

The resource copy must run at process-classes

maven-jar-plugin takes a single classesDirectory, and classes-jdk21 holds only .class files — so the classified jar needs resources copied in or it ships without cfml.dictionary's 231 XML files.

That copy cannot move later than process-classes. Setting outputDirectory on a compiler execution leaks into what the reactor hands dependent modules, so cfml.parsing's tests resolve cfml.dictionary to classes-jdk21. Copy the resources at prepare-package instead and all 326 tests fail with:

java.lang.IllegalArgumentException: Problem loading dictionaryconfig.xml

which reads like a missing resource rather than a phase-ordering problem. I hit exactly that while building this, so the pom carries the explanation at the line where someone would otherwise move it.

skipIfEmpty stops the pom-packaged parent emitting and deploying a spurious cfparser-VERSION-jdk21.jar, which it did until that was added.

CI runs on both runtimes

gradle.yml gains a java-version axis of [11, 21] across all three operating systems, with fail-fast: false so one platform failing does not mask the others.

This matters more than it might look: compiling to 11 on a 21 JDK cannot catch a problem that only appears on an 11 runtime, and this environment has no Java 11 available and cannot download one — the proxy blocks Adoptium and foojay. The matrix is the only thing that actually exercises Java 11.

Gradle builds the Java 11 line only. Maven is what publishes, so the classifier is produced there.

Verification

• 326 tests, ./gradlew build
• CFLint 675 against the Java 11 parser — the real check that dropping the baseline is safe downstream
• mvn deploy to a local file repository produces main, jdk21, sources and javadoc for both modules, and no parent jar
• Both variants carry identical class and resource counts (cfml.dictionary: 20 classes, 231 XML each), differing only in bytecode level

Not verified here

I could not execute the suite on a real Java 11 JVM — hence the CI matrix. Until that runs, Java 11 support rests on bytecode level and API-surface checking, not on observed behaviour.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GzpZFd4rnE1Yi2sVHAji35

---

Generated by Claude Code