[BLOCKED/DRAFT] refactor: migrate Xtend to Java - com.avaloq.tools.ddk.xtext.test.core (Tag)

[joaodinissf]

⚠️ DRAFT CHECKPOINT — DO NOT MERGE / DO NOT FLIP

This bookmarks completed migration work but is blocked on an unresolved question. Kept as a draft so the work isn't lost while we sort it out.

What this contains

Converts Tag (the last .xtend in the module) from Xtend to Java, keeping @Active(TagCompilationParticipant) + @Retention(RUNTIME) + the processor + the org.eclipse.xtext.xtend.lib MANIFEST dependency, and removes the module's Xtend build infrastructure (.classpath/.project/build.properties/xtend-gen). Local gate (compile + checkstyle + pmd + spotbugs, -DskipTests) is green.

Why it's blocked

Tag is an Xtend active annotation: TagCompilationParticipant runs at Xtend-compile time and assigns each @Tag-annotated field a unique integer (from COUNTER_BASE = 10000). Critically:

• DDK declares no @Tag fields itself — the real consumers are downstream (closed-source ASMD monorepo).
• So DDK CI cannot validate that the macro still fires after Tag becomes a Java @interface. The failure mode (uninitialized tag = 0) is runtime, and our local gate runs with -DskipTests.
• An Xtend annotation compiles to a Java @interface+@Active, so this is plausibly bytecode-equivalent (and refactor: migrate all Xtend files to Java 21 #1274 did the same) — but that rests on the Xtend compiler recognizing a Java-authored @interface+@Active as an active annotation, which only a downstream build can confirm.

What we need to do to unblock (pick one)

1. Confirm the Xtend compiler treats a Java @interface+@Active as an active annotation and validate downstream (ASMD) that @Tag int FOO still auto-numbers → then flip.
2. Eliminate the macro: replace compile-time auto-numbering with explicit unique-int constants on every @Tag field (incl. downstream), then drop Tag/TagCompilationParticipant entirely — a coordinated cross-repo refactor.
3. Defer Tag to the dedicated active-annotation/macro-retirement effort and keep it as Xtend until then.

🤖 Generated with Claude Code

[rubenporras]

I think we can do this if we want to finally get rid of Xtend. Alternatively, if we accept that downstream projects can also migrate away from xtend, they should use com.avaloq.tools.ddk.xtext.test.TagExtension, which I introduced for that purpose. Because this will likely take same time I think this PR makes sense.