Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343351

Summary:	[editor] Allow to change resource implementation on "save as"
Product:	[Modeling] EMF	Reporter:	Jan Koehnlein <jan>
Component:	Edit	Assignee:	Ed Merks <Ed.Merks>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	ed
Version:	2.7.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Jan Koehnlein

2011-04-20 04:12:04 EDT

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).

Comment 1 Ed Willink

2011-04-20 04:52:49 EDT

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);
        }

Comment 2 Ed Merks

2011-04-20 09:32:33 EDT

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...

Comment 3 Ed Willink

2011-04-20 09:46:33 EDT

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.

Comment 4 Ed Merks

2011-04-20 09:49:27 EDT

I see, so you're not asking all generated editors to be changed...

Comment 5 Ed Merks

2011-05-12 16:22:34 EDT

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.

Comment 6 Ed Willink

2011-05-13 00:55:44 EDT

(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).

Comment 7 Ed Merks

2011-06-02 11:40:13 EDT

The fix is available in 3.7RC3 and later.