Export: classes named in extension declarations are not build dependencies of the export model #1554

An export model can call Java through extension declarations:

extension com::foo::^export::Bar
export lookup x::TypeN as qualified name [isBlaBla(this.eContainer)] { object-fingerprint; }

The class is stored as a plain name (Extension: 'extension' extension=QualifiedID) and only resolved while the Java is generated, after the builder has recorded the model's dependencies. It is therefore neither an imported name nor a reference of the .export. Changing Bar doesn't rebuild the model, so a signature change leaves the generated code stale, typically as a compile error in it, until the .export is touched or the project is cleaned. This predates the Xbase migration (#1405); the 2017 grammar comment already says "Alas, we can't link xtend files".

Checked on master with a plugin test that feeds isAffected a Java change to a resolvable extension class: not affected, while changes to EClass or AbstractExportedNameProvider are.

Scope has the same extension rule (Scope.xtext:30-31) and resolves it the same way (ScopeExpressionTranslator), so it likely has the same gap (not yet tested).

Proposed fix: add the extension classes to the model's imported names when its resource description is computed. Java changes to them, and Xtext changes to Xtend-generated extension classes, would then re-queue the model.

🤖 Generated with Claude Code