build: Modernise JVM build to align with apex-parser 5.x#7
Closed
kjonescertinia wants to merge 2 commits into
Closed
build: Modernise JVM build to align with apex-parser 5.x#7kjonescertinia wants to merge 2 commits into
kjonescertinia wants to merge 2 commits into
Conversation
Replace antlr4-maven-plugin with exec-maven-plugin + build-helper-maven-plugin running ANTLR 4.13.2 directly, so the JVM and (eventually) npm sides share a single generator. ANTLR runtime bumped 4.9.1 -> 4.13.2 to match apex-parser and unblock downstream apex-ls. Maven plugins, JUnit, and Java toolchain all brought current; publishing switched from the legacy nexus-staging-maven-plugin (OSSRH s01) to central-publishing-maven-plugin (Sonatype Central Portal). CI Java bumped 8 -> 11 since <release>8</release> requires JDK 9+ to compile. Refs #6
ANTLR copies @lexer::members and @parser::members blocks verbatim into generated sources, so the existing Java clearCache() helper breaks the TypeScript target. Split each grammar into a language-neutral base file and a per-target overlay (mirroring apex-parser): - /antlr/BaseVF{Lexer,Parser}.g4: shared rules, no embedded actions - /jvm/antlr/VF{Lexer,Parser}.g4: thin overlays adding the Java helper via @members and importing the base The npm side will add its own (action-free) overlays in a follow-up. clearCache() still appears on both VFLexer and VFParser on the JVM side, preserving the apex-ls API surface. Refs #6
6 tasks
Contributor
Author
|
Superseded by #8 — JVM and npm modernisation combined into a single PR since the grammar split has no value without the npm overlay that consumes it, and CI runs both halves. |
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.
Summary
antlr4-maven-pluginwithexec-maven-plugin+build-helper-maven-pluginrunning ANTLR 4.13.2 directly. The JVM and (eventually) npm sides will share a single generator pointed at/antlr, removing the per-target.g4copy step.apex-ls, which currently sees conflicting ANTLR runtimes.<source>1.8</source>/<target>1.8</target>→<release>8</release>) all brought current.nexus-staging-maven-plugin(OSSRHs01) tocentral-publishing-maven-plugin(Sonatype Central Portal).<release>8</release>);PublishMaven.ymlserver-idbumpedossrh→centralto match the new plugin.This is the first PR in the modernisation tracked in #6 — JVM-only, npm side stays on
antlr4tsand is unchanged here.Test plan
mvn clean packagefromjvm/— green, 2/2 tests pass, jar+sources+javadoc all built locallynpm run init-jvm— generatesVFLexer.java/VFParser.java/listeners/visitors intotarget/generated-sources/antlr/com/nawforce/vfparser/apex-lsbuilds against this snapshot once published (separate from this PR)Notes for the next release
MAVEN_USERNAME/MAVEN_TOKENGH secrets must be a Sonatype Central Portal user token, not the legacy OSSRH one. Worth confirming before the next release fires.OSSRH_GPG_SECRET_KEYsecret name still works with the new plugin; left as-is to avoid touching secret config in this PR.1.1.0in the pom; bump at release time. Sonatype Central won't accept republishing1.1.0, so the next deploy needs a version bump regardless.