Community
Participate
Working Groups
The GenericEditor serializes certain models slightly differently than the Sample Reflective Ecore editor. The differences occurs with models containing EClasses with Extended meta data to support XML serialization, when these are included in XMIResources. In this case, the serialization shouldn't use the Extended meta data, but it does, so you may end up with XML that cannot be read as proper XMI for the model. See https://www.eclipse.org/forums/index.php/t/1089914/ for details of the case. The problem is that the GenericEditor sets the load option XMLResource.OPTION_RECORD_UNKNOWN_FEATURE to Boolean.TRUE before loading, and that this in turn (somehow) sets the EXTENDED_META_DATA option in the Resource's defaultSaveOptions, which instructs the save method to serialise as XML, rather than XMI). If I clear the load options in the debugger, before the initial load, the EXTENDED_META_DATA options is not set, and the serialization is proper XMI. I suggest that GenericEditor does not set the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option to TRUE, so this side-effect is avoided.
Thank you for the report. We will discuss this and post updates here.
Hallvard, could you please provide a small example to reproduce the issue? Thank you!
Created attachment 273078 [details] Project that demonstrates the bug This is a minimal project demonstrating the bug. It contains two models, one using XML annotions that changes how models are serialized, the other depending on the first, but using XMI serialization. Two examples instances are provided, one (model/Path.xmi) extension) that can be read by the Sample Reflective Ecore Editor, but not by ECF's Generic Editor (it can be read, but some attributes are ignored), and another (model/Path.bug527110b) that can be read by the Generic Editor (is in fact, written by it), but not by the Sample Reflective Ecore Editor. The project declares the Generic Editor as the editor for the bug527110b extension, so it a runtime Eclipse can be launched and used to open Path.bug527110b with either editor.
New Gerrit change created: https://git.eclipse.org/r/124027
The fix seems to force all Resources to be save with XMLResource.OPTION_EXTENDED_META_DATA set to false. But won't this break Resources that should be serialized as XML? Resources that (already) are (supposed to be) stored as XML should be loaded and saved as XML. It's the (default) Resource implementation (the one registered for the file extension in the global or ResourceSet registry) that should decide, not the editor. The test needs to check that both cases work properly, when the resource is an XMLResource it should be serialized as XML, when the resource is an XMIResource, it should be serialized as XMI.
Hallvard, could you please test the Gerrit change and see if this fixes your issue?
I have to move it as we have to release next week. We will merge it after a thorough test after the current release.
Gerrit change https://git.eclipse.org/r/124027 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=c955244debb12c65ebbd25785a842e017038e523
We deprecated the save/load methods of ResourceSetHelpers that did not accept resource load/save options and introduce new methods to replace them, that expect these as a parameter. Clients are now responsible for passing in the expected options and the helper class should not specify any. This affects the GenericEditor and its subclasses. The GenericEditor also throws a new PartInitException, if there were errors while loading the resource.
