Skip to content

PoC: resolve patched ANTLR generator from the target platform (Maven Central)#1432

Draft
joaodinissf wants to merge 1 commit into
dsldevkit:masterfrom
joaodinissf:poc/antlr-generator-from-maven-central
Draft

PoC: resolve patched ANTLR generator from the target platform (Maven Central)#1432
joaodinissf wants to merge 1 commit into
dsldevkit:masterfrom
joaodinissf:poc/antlr-generator-from-maven-central

Conversation

@joaodinissf

Copy link
Copy Markdown
Collaborator

What

Proof of concept: make the patched ANTLR 3.2 generator used by the Generate*.mwe2 grammar workflows resolvable from the target platform (Maven Central) instead of from the 1.4 MB binary jar committed to com.avaloq.tools.ddk.workflow in #1308.

Adds a single PDE/Tycho Maven location to ddk-target/ddk.target:

  • org.eclipse.xtext:xtext-antlr-generator:2.1.1 — the AntlrToolRunner toolrunner that Xtext's AntlrToolFacade invokes.
  • org.xtext:antlr-generator:3.2.1 — the fat patched-ANTLR-3.2 tool jar (provides org.antlr.Tool).

PDE wraps both non-OSGi jars as bundles (missingManifest="generate"). includeDependencyDepth="none" keeps it from dragging in a second log4j.

Why this is low risk / low complexity

The generator we currently host is this Maven artifact — I verified the committed antlr-generator-3.2.0-patch.jar is itemis's patched ANTLR fat jar, and org.eclipse.xtext:xtext-antlr-generator (donated to Eclipse, on Central since 2014) carries the identical de.itemis.xtext.antlr.toolrunner classes and declares the fat jar as a transitive dependency. No repackaging, no building, no dead p2 repo — a declarative one-location target edit.

How to test locally

  1. Set ddk-target/ddk.target as the active target platform; reload it.
  2. Confirm the two generated bundles (xtext-antlr-generator, antlr-generator) resolve in the target contents.
  3. Optionally remove the <classpathentry kind="lib" path="antlr-generator-3.2.0-patch.jar"/> line from com.avaloq.tools.ddk.workflow/.classpath and re-run a Generate*.mwe2 launch to prove the generator now resolves from the target.

Scope

Purely additive — the committed jar is left in place so the branch stays green. If local testing confirms the target route works, the follow-up removes the committed jar + its provenance note.

🤖 Generated with Claude Code

The Generate*.mwe2 grammar workflows need the patched ANTLR 3.2 generator
(the org.antlr.Tool plus the itemis AntlrToolRunner that Xtext's
AntlrToolFacade invokes). Today the launch classpath pulls this from a
1.4 MB binary jar committed to com.avaloq.tools.ddk.workflow
(antlr-generator-3.2.0-patch.jar, added in dsldevkit#1308).

That exact generator was donated to Eclipse and published on Maven Central
years ago: org.eclipse.xtext:xtext-antlr-generator:2.1.1 is the toolrunner,
and it pulls org.xtext:antlr-generator:3.2.1 - the fat patched-ANTLR-3.2
tool jar. So we can let the target platform provide it instead of hosting a
binary or relying on the dead itemis p2 repository.

This PoC adds a PDE/Tycho Maven location to ddk.target that brings both
artifacts in as PDE-wrapped bundles (missingManifest=generate). It is purely
additive - the committed jar is left in place so the branch stays green -
and is meant for local verification: set ddk.target active, confirm the two
generated bundles resolve, then (optionally) drop the lib entry from
com.avaloq.tools.ddk.workflow/.classpath and re-run a Generate*.mwe2 to
prove the generator now resolves from the target.

If that holds, the follow-up is to remove the committed jar and its
provenance note and rely solely on Maven Central.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant