Community
Participate
Working Groups
Currently, the editor allows to convert between Ecore to EMOF on "save as" only. There is a hard wired constraint in the code that checks for the resp. file extensions and creates a new Resource with the new URI if it matches. Given the growing amount of Resource implementations and thereby persistence formats, it would be nice to allow to convert using other resource implementations, too. A possible strategy would be to replace the Ecore / EMOF condition check and try to create a new resource in all cases. If it fails, there could be a fallback to the old behvior (i.e. setting the new URI on the existing resource).
This originates from the TMF newsgroup "How to transform xText to XMI" thread, news://new.eclipse.org:119/iojfp0$66f$1@news.eclipse.org. I observed that unfortunately, although an Xtext 'resource' can be loaded by the Sample Ecore Editor, any attempt to save the result as XMI in order to see the underlying CS model fails to serialize as XMI producing text instead. Jan identified that the following code for save causes the Xtext resource to serialize to an XMI extension. (EcoreEditor.doSaveAs) if (currentExtension.equals(ECORE_FILE_EXTENSION) && newExtension.equals(EMOF_FILE_EXTENSION) || currentExtension.equals(EMOF_FILE_EXTENSION) && newExtension.equals(ECORE_FILE_EXTENSION)) { Resource newResource = resourceSet.createResource(newURI); newResource.getContents().addAll(currentResource.getContents()); resourceSet.getResources().remove(0); resourceSet.getResources().move(0, newResource); } else { currentResource.setURI(newURI); }
Is this request just for the reflective editor? One problem that's not addressed with this approach is when the desired type is based on content type registration rather than just on extension registration. But extension registration is more common, so it's no worse than now...
No. It affects both editors. Since the observed limitation can only occur when an XtextResource has been registered to facilitate the loading of a textual resource which will mean that it is using a genmodelled Xtext CS model. Repro: With Xtext installed, open a *.xtext file with either Sample Ecore Editor or Sample Reflective Ecore Editor, then Save As *.xmi.
I see, so you're not asking all generated editors to be changed...
Whenever the extension changes, we create a new resource, which might well be of a different type. This should support more conversion scenarios. The change is committed to CVS for 2.7.
(In reply to comment #5) > This should support more conversion scenarios. Excellent. I hadn't thought of that. Presumably *.xmi to a corresponding '*.xtext' will work and so *.ecore to *.oclinecore (or perhaps *.emfatic).
The fix is available in 3.7RC3 and later.
