Deresolve uses TokenResolvers instead of ReferenceResolvers, when saving an model with eProxies to textual format

[rolftheunissen]

To save an excising model in xmi format in a concrete textual format, the xmi file can be open with the sample reflective model editor. Then it can be saved as a file in textual format by saving it using 'Save as ...' with the corresponding extension.

The xmi file may contain references to other files. If these eProxies are resolved before saving, the serialization is correct.
If the eProxies are not resolved before saving the model, TokenResolvers are used to deresolve the references instead of ReferenceResolvers.

If the model contains unresolved proxies, these proxies should be resolved before saving the model.

To reproduce:

1. Load an xmi file with references to other files, with the sample reflective model editor.
2. Save file directly without exploring or validating the model to a textual file.

[mirkoseifert]

I'm not sure how to handle this. You're probably suggesting that the generated resource class should resolve all proxies right before it is saved. Howerer, I'm not sure whether this is a good default behavior. I distinctly remember that there were cases where we explicitly rely on the fact the proxies are not resolved before saving (e.g. in JaMoPP). Is there another way to fix this?

@jjohannes What's your opinion?

[jjohannes]

I think the problem described here is another one. Usually, references are resolved automatically when the model is serialized at the latest.

In JaMoPP, which Mirko was referring to, we have a specialized implementation that does not resolve proxies during printing, because this can be very expensive.
(see: https://github.com/DevBoost/JaMoPP/blob/master/Core/org.emftext.language.java.resource/src/org/emftext/language/java/resource/JavaSourceOrClassFileResource.java#L178)

I think the issue is something different. @rolftheunissen: Could you post an example to reproduce the problem?

[rolftheunissen]

I am trying to reproduce the problem in a small example. So far the problem does not occur when the type of the referenced items is defined in the same metamodel. I can see in the editor that the other resource is loaded while saving the model.

The problem does occur in our real models where the type of the elements that are referred is defined in another metamodel. I will try to construct an example later.