Community
Participate
Working Groups
It has been identified that integration with XText is difficult because of usage of XMIResource and GMFResource (extends XMIResource). It is also true in the cases when someone wants to use a XMLResource, GMF Tooling should try to remove all these XMIResources and use the abstract Resource instead. The resource type could be configured in tooling models (XML, XMI, XText...)
This is only necessary for the semantic model, the notation model does not need to be changed.
GMFResource is for semantic model, so I don't see why the knowledge that it is of specific type may hurt anyone. I know only a few hardcoded casts to XMIResource for semantic model and for now I don't see any reasons for this to be hardcoded. I have recently implemented a prototype that uses the very special resource implementation storing both semantic (xText) and diagram models in one xText+xml resource. I am not suggesting this approach obviuosly, this is just to confirm that generated GMFT diagram after just a few tweaks may work without a problems with different resource implementations. I think we will do that next M, will add the M information when I will have a rights to do that. Also, back to xText integration, I see a lot of not yet mentioned problems here, at the xText side, will comment on that at #359633.
(In reply to comment #2) > GMFResource is for semantic model, * sorry, obviously meant "notation model" not semantic
Just verified that in the RC2 code base, templates contain neither GMFResource not XMIResource'. Closing bugzilla.
