Hi,
I never meant that facade should be dedicated only to the tooling, nor contain UI contributions. That's definitely my goal to get some basic layer, required on top of the UML model + profile, that allows other layers (tooling / textual modeling / codegen / doc gen / etc.) to commonly access the UML-RT models in the most basic operations, as reading it, querying it, and basic creation of its elements. Of course for the tooling, there is more needed, as for example the copy and paste of elements, the dialogs to ask for parameters when creating new elements, workflows for creating several elements at once, etc. But again, we all agree I think this is not the role of the facade. This is the role of the tooling. The facade only brings the core facilities. And implementing another metamodel inheriting from the UML one would not forbid to run out of OSGi, as this would be a simple metamodel implementation. so I think tooling and other components have the same needs for that base component. Pure code generation, documentation generation or validation would theoretically only need read-only access to the model. Textual modeling and tooling would need the same features, read and update the model.
Since the beginning, it seems there is a misunderstanding about gmf runtime and element types. Even if GMF stands for Graphical Modeling Framework, some parts of the framework are not dedicated to graphical editing. In such, Element Types are absolutely not something tied to graphical tooling. These are just a layer on top of a metamodel, to bring some ability to extend the edition of the models and also give some abstraction to this metamodel. It also bring a nice aspect oriented programming ability, where users can further more extend the edition of the model, by simply adding/removing/replacing actions on top of basic edition. However, as demonstrated in the past, the framework was badly coupled between UI and headless stuff, and they would require also to work out of Eclipse, e.g. a few registries should be populated out of the eclipse environment. That's why codegen component rightly decided to go for its own primitives on top of UML-RT.
Concerning going to a Ecore metamodel being a synthesis of the UML metamodel + the profile:
What is usually done when defining a profile is to define the domain model and then to map it on the UML metamodel into a UML profile. The synthesis of the metamodel + profile would just be a way to get back to a similar metamodel. One of the main reasons for going to a synthesed metamodel would be to get access directly to Xtext grammars, where hybrid textual modeling would just be a plain implementation of the grammar on top of that metamodel. This would avoid the usage of the intermediate metamodel, as done for code generation. For model compare for example, I am concerned about the ability of EMF Compare component to integrate the current solution, as it seems it will have the same drawbacks: redeveloping inside the integration EMF Compare / Papyrus-RT all the "smartness" that we implemented in codegen or in tooling.
But, again, Christian's solution is targeting 1.0. Not the one I have in mind ;-)
Cheers,
Rémi