Repository navigation
Compile the pre-26 NMS modules with JDK 21 through a toolchain - #177
Merged
Merged
Conversation
The first semver release of Codex failed in codex-nms-v1_20_1:
spigot-1.20.1-R0.1-SNAPSHOT.jar(.../WorldServer.class): error: Cannot
attach type annotations @javax.annotation.Nullable to WorldServer.a:
class file for com.mojang.datafixers.util.Pair not found
Since JDK 22, javac reads type annotations from the jars it compiles
against, so it needs classes those annotations reference. On the CI
runner datafixerupper wasn't on the module's classpath. The build runs
on JDK 25 because the main modules need WorldEdit's Java 25 classes,
but only the 26.x NMS modules need 25 themselves.
codex-nms now selects the compiler JDK with jdkToolchain ${nms.jdk},
defaulting to 21, and the 26.2/26.3 modules set it to 25. The shared
release workflow writes a toolchains.xml for both JDKs. Without one, as
in a local build, the compiler falls back to the JDK Maven runs on.
Reproduced the CI error locally (JDK 25, no datafixerupper on the
classpath) and confirmed the 21 toolchain compiles that module. 26.3
compiles with the 25 toolchain.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Secz6aiBJ7U8im8tnYhyLA
Travja
pushed a commit
to magemonkeystudio/.github
that referenced
this pull request
Oct 23, 2026
The first semver release of Codex failed in its seventh NMS module, but Maven had already deployed the modules built before it. That left codex-parent, codex-bungee and codex-api 1.2.0 in the releases repository without the rest of the release. - Pass -DdeployAtEnd=true, so maven-deploy-plugin uploads only after every module has built. A failure partway through no longer leaves a partial release, and the workflow already removes the tag in that case. - Write ~/.m2/toolchains.xml with the runner's JDK 21 and 25 before deploying, so modules can compile with a different JDK than Maven runs on. Codex's pre-26 NMS modules use the 21 toolchain (magemonkeystudio/codex#177), because javac on JDK 22+ rejects their Spigot jars. Projects without jdkToolchain configuration ignore it. Tested locally: with deployAtEnd every module logs "Deferring deploy" and nothing is uploaded before the last module finishes. The toolchains snippet produces valid XML, including when a JDK is missing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Secz6aiBJ7U8im8tnYhyLA
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes the failed
1.2.0release (run 40011583260).What failed
BuildTools succeeded for every Spigot version. The deploy then failed compiling
codex-nms-v1_20_1on JDK 25:Since JDK 22,
javacreads type annotations from the jars it compiles against, so it now needs classes those annotations reference. On the runner,datafixerupperwasn't on that module's classpath. The release runs on JDK 25 because Codex's main modules need WorldEdit/WorldGuard's Java 25 classes, but only the 26.x NMS modules need 25 themselves.Change
codex-nms/pom.xml: the compiler picks its JDK throughjdkToolchain=${nms.jdk}, default21. All NMS modules inherit this.codex-nms-v26_2andcodex-nms-v26_3setnms.jdkto25, since their Spigot jars are Java 25 class files.The shared release workflow writes a
toolchains.xmlwith the runner's JDK 21 and 25 (.githubpatch0006, which also addsdeployAtEnd). Without atoolchains.xml, as in a local build, the compiler just uses the JDK Maven runs on.Before merging / re-running the release
.githubpatch0006is applied. Without thetoolchains.xmlit writes, the compiler falls back to JDK 25 and the release fails the same way.1.2.0upload is removed fromrepo.travja.devreleases:codex-parent,codex-bungeeandcodex-api1.2.0. The failed run deployed those modules before it reached the broken one. The1.2.0tag was already removed by the workflow.Testing
On a real Spigot 1.20.1 jar from BuildTools:
datafixerupperexcluded from the classpath (as on the runner).Toolchain in maven-compiler-plugin: JDK[…java-21…]) and the build succeeds. Thedelombokstep still prints the message, but it's non-fatal and was already there.codex-nms-v26_3against the real 26.3 jar: compiles with the JDK 25 toolchain.toolchains.xml, both modules fall back to the running JDK instead of failing.Generated by Claude Code