docs: record why the Gremlin ANTLR and Groovy versions are frozen - #5536
Merged
Conversation
The reasoning for these pins lived only in closed PR threads and the Dependabot config, neither of which a developer editing gremlin/pom.xml would look at. Two Dependabot PRs were attempted and abandoned against these properties before the constraint was understood. gremlin/pom.xml now records that both properties are dictated by TinkerPop: groovy.version is held on the 4.0.x line because gremlin-groovy is built against it, and antlr4.version is held at 4.9.1 because gremlin-language ships a parser generated by the ANTLR 4.9.1 tool while ANTLR 4.10 changed the serialized ATN format. It also states which updates are still wanted (Groovy 4.0.x patches) and why ANTLR has no Dependabot ignore rule. engine/pom.xml records that its own antlr4.version is deliberately independent and free to track the latest, so the divergence from gremlin does not read as drift. Also ignores the E2E harness test output. Playwright writes playwright-report/ and test-results/ on every local run and neither was ignored, so a local run left untracked artifacts in the tree. Comments only: mvn validate passes and the effective poms still resolve antlr4.version 4.9.1 / groovy.version 4.0.32 for gremlin and antlr4.version 4.13.2 for engine. Refs #5535
Contributor
|
Tick the box to add this pull request to the merge queue (same as
|
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
🟢 Coverage ∅ diff coverage
Metric Results Coverage variation Report missing for 89d44f31 Diff coverage ✅ ∅ diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (89d44f3) Report Missing Report Missing Report Missing Head commit (7b3c711) 178704 121262 67.86% Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#5536) 0 0 ∅ (not applicable) Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%1 Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Contributor
📜 License Compliance Check✅ License check passed. See artifacts for full report. License Summary (first 50 lines) |
ReviewDocs and What I checked
Minor, non-blocking
Convention checkConsistent with CLAUDE.md: no new dependency, no version change, no behaviour to test (the "no unit tests" checkbox is justified here). Nothing to flag on performance or security - the diff touches neither code path nor build resolution. LGTM. |
2 tasks
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5536 +/- ##
============================================
+ Coverage 65.31% 65.70% +0.39%
- Complexity 1114 1117 +3
============================================
Files 1748 1748
Lines 146712 146712
Branches 31356 31356
============================================
+ Hits 95827 96401 +574
+ Misses 37933 37364 -569
+ Partials 12952 12947 -5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2 tasks
robfrank
added a commit
that referenced
this pull request
Aug 14, 2026
) (cherry picked from commit 5a06925)
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
1 participant
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.
What does this PR do?
Records, in the files a developer actually edits, why two Gremlin dependency versions are frozen. Also ignores the E2E harness test output.
Comments and
.gitignoreonly. No behaviour change. No version is raised, no dependency added or removed.gremlin/pom.xml— explains thatgroovy.versionandantlr4.versionare both dictated by TinkerPop, states which updates are still wanted, and points at Upgrade TinkerPop to unlock the ANTLR and Groovy versions frozen in gremlin/pom.xml #5535.engine/pom.xml— records that its ownantlr4.versionis deliberately independent and free to track the latest, so the divergence fromgremlindoes not read as drift..gitignore— ignoresplaywright-report/,test-results/,blob-report/, and the tworeports/directories.Motivation
The reasoning for these pins lived only in closed PR threads and a comment in
.github/dependabot.yml, neither of which anyone editinggremlin/pom.xmlwould look at. Two Dependabot PRs were attempted and abandoned against these exact properties (#3235 ANTLR, open since January with 13 failing checks; #4969 Groovy, 6 failing checks) before the constraint was understood. Without a comment at the property itself, a third attempt is a matter of time.The
.gitignoregap is smaller but real: Playwright writesplaywright-report/andtest-results/on every local run and neither was ignored, so simply running the Studio E2E suite locally left untracked artifacts in a developer's tree.e2e-js/reports/ande2e-studio/reports/receive JUnit XML in CI and had the same gap.Related issues
Refs #5535, the tracking issue for the TinkerPop upgrade that unlocks both frozen versions at once.
Context: #3235 and #4969 (both closed as structurally unmergeable), #5534 (the majors-only Groovy ignore rule), #5216 / #5217 (the shading arrangement that depends on the pinned ANTLR).
Additional Notes
The substance of the two pins, for reviewers:
ANTLR is module-local and the divergence is intentional.
gremlin/pom.xml:45gremlin-language3.8.1 ships a parser generated by the ANTLR 4.9.1 tool. ANTLR 4.10 changed the serialized ATN format — theBASE_SERIALIZED_UUIDfield in 4.9.1'sATNDeserializerdoes not exist in 4.13.2 — so a 4.13 runtime cannot deserialize it.engine/pom.xml:46The
gremlincomment also records why ANTLR has no Dependabot ignore rule while Groovy does: ignore rules match dependency coordinates rather than modules, and 4.9.1 sits below the engine's 4.13.2, so any blocking range would silently freeze the engine too.Groovy is pinned to the 4.0.x line because
gremlin-groovy3.8.1 is built against it (TinkerPop 3.8.1 declaresgroovy.version4.0.25). ArcadeDB deliberately runs 4.0.32, ahead of TinkerPop, so 4.0.x patches are wanted and still tracked; only majors are ignored.Verification run locally:
xmllintclean on both poms.mvn -pl engine,gremlin validate→ BUILD SUCCESS.gremlinantlr4.version4.9.1 /groovy.version4.0.32 andengineantlr4.version4.13.2, confirming the comments are inert..gitignorerule verified against a real directory withgit check-ignore; with all five present,git statusreports only the three intended file modifications.git ls-filesconfirms no currently tracked file falls under the new ignore rules, so nothing is silently dropped from version control.Checklist
I have run the build using— not run in full. The diff is XML comments andmvn clean package.gitignore;mvn -pl engine,gremlin validatepassed and the effective property values are unchanged, which is the relevant evidence. CI covers the full build.My unit tests cover both failure and success scenarios— no unit tests added. There is no behaviour to test; the change is documentation and ignore rules.