Hi team,
@Patrick: I do not have the implementation details from Christian, but I don't see there issues on using the new facade on OSGi. It should not involve more than EMF and UML2 plugins, which are already supported out of Eclipse & OSGi (at least, it should, or you would not even be able to read the model itself).
@all: We indeed discussed yesterday on such improvement on facade support with Philip last week. This is one of the major topic IMO for great support for DSLs for Papyrus and its derivative products. The advantage of using an EMF approach would be indeed the integration with external tools like EMF compare, xtext grammars, QVTo transformation, all the tools that should be EMF based, and that can have some troubles to integrate with UML2 world would be quite transparent to the user.
Current approach with element types fits nicely with GMF runtime, and it could be seen as slightly higher level, but the 2 main drawbacks are the fact that the metamodel complexity is hidden in the configurations and that we cannot enforce that the model is edited through this framework. Xtext is for example not aware of that framework, and tricks have to be used to reuse it. We could see that issue with textual modeling.
I was thinking however to a facade implementation where the elements would really inherit from the UML metaclass, not an association to this class itself. I do know it breaks slightly the UML philosophy, where stereotypes can be removed/added on the fly. But in the case of stereotypes defining new concepts, as the capsule one, I would not be so worried about that side effect. It would cause issues in the case of annotating stereotypes, which should be seen more as associations in this case. This implementation would have of course many drawbacks, but I would be curious to setup also a prototype for that approach. I did not yet think carefully about implementation details. One of the advantage I see here is that we would not maintain a "glue element", but we would have directly a compatible element. This would avoid switching with toUML() and other artifices to real implementation elements.
I would however be interested to investigate your proposal, Christian, that seems a really interesting step ! :) I am for example curious to discover how notifications can be handled, I remember that was an issue Florian had to work on his facade prototype a few years ago.
Cheers,
Rémi