Migrate the Scope generator off classic Xtend onto Xbase +

[rubenporras]

JvmModelInferrer

Summary
The com.avaloq.tools.ddk.xtext.scope plugin compiled the embedded Expression DSL to Java through expression.generator.CodeGenerationX / CompilationContext, whose type system is the legacy classic Xtend runtime (org.eclipse.xtend.expression.,
org.eclipse.xtend.typesystem.emf.). That was the only reason the plugin required those bundles.

This PR replaces the IGenerator2-based ScopeGenerator with an Xbase JvmModelInferrer, introduces a self-contained (Xtend-free) expression-translation layer, deletes the classic-Xtend execution context, and removes org.eclipse.xtend and
org.eclipse.xtend.typesystem.emf from the scope plugin.

Key decisions
Decision Rationale
Scope generation moves to a JvmModelInferrer + Xbase JvmModelGenerator Same pattern as Format/Check; lets the standard XbaseCompiler emit the provider classes. The
*ScopeProvider/*ScopeNameProvider are now inferred JVM types rather than hand-templated .java.
Hybrid expression backend: an Xbase translator + a string compiler fallback String + concatenation (very common in .scope) has no operator_plus in xbase.lib — Xbase special-cases it in its compiler — so it can't be pre-linked as an XExpression tree. We translate to Xbase what maps cleanly and fall back to a faithful port of the legacy string output for +, arithmetic and relational operators. Model-type names resolve via imported EPackages, not the classpath In real sources, (Cast)x / typeSelect(T) / T.isInstance(x) name EMF model types (FormDef, ILogicalTable, intfdef::AlternatingGroup), not Java FQNs. javaType resolves them through the model's imported EPackages → GenModelUtilX.instanceClassName, exactly as the legacy EmfRegistryMetaModel did. findDeclaredType would fail on these. .ext (JAVA extension) support dropped Scope sources no longer reference Xtend extension files; removed the .ext-reading validation and the isJavaExtensionCall/isExtension generator branches. factory becomes a direct Xbase static call Must be written Type.method(args); the generator resolves the type to a JvmDeclaredType.qualifiedName and emits the static call. Bare factory foo() is no longer supported.
dsl-devkit only; output need not be byte-identical Downstream ASMD .scope/.ext sources and their committed generated providers are regenerated by the author separately.
Implementation
New (scope plugin):

jvmmodel/ScopeJvmModelInferrer.java — infers the provider + name-provider JVM types; attaches method bodies as strings; framework types emitted fully-qualified so the unit needs no imports. jvmmodel/ScopeExpressionTranslator.xtend — translates the Expression AST → XExpression (literals, if/list, variable & this calls, boolean/equality/relational ops linked to xbase.lib, getter navigations, extension calls, casts/typeSelect/isInstance, method calls). jvmmodel/ScopeExpressionCompiler.xtend — Xtend-free Java-string fallback; ports CodeGenerationX/ExpressionExtensionsX output branch-for-branch, minus the .ext paths.
jvmmodel/ScopeTranslationContext.xtend — variables, implicit parameter (type resolution) vs implicit-var name (emitted this binding), model-type resolver; newCompilationContext(...) replaces the legacy CompilationContext.clone(...).
generator/ScopeModelTypeResolver.java — model-name → EClassifier over imported EPackages (alias-aware).
expression/jvmmodel/ExpressionJvmModelInferrer.xtend + Expression/Scope grammar updates to embed Xbase (with src-gen regeneration). Removed:

generator/ScopeGenerator.xtend (IGenerator2).
ScopingGeneratorUtil.getCompilationContext and its classic-Xtend inner classes (ScopeExecutionContext, ScopeResource) + orphaned helpers/imports.
ScopeValidator.checkExtensions + its message key.
org.eclipse.xtend, org.eclipse.xtend.typesystem.emf from META-INF/MANIFEST.MF.
Verification
mvn clean verify of the expression + scope plugins: BUILD SUCCESS with the Xtend bundles removed.
A grep of the plugin confirms no classic-Xtend imports remain (only a doc-comment mention of EmfRegistryMetaModel).
Caveats / follow-ups
dsl-devkit has no .scope input files, so the inferrer never runs during verify — only compilation is checked. Generated-Java output fidelity must be validated by regenerating ASMD in Eclipse. The expression plugin itself still requires Xtend while CompilationContext.java exists (separate increment). Next: apply the same playbook to the export plugin.