ThitGaRang / emf-profiles

Automatically exported from code.google.com/p/emf-profiles
0 stars 0 forks source link

Save unloads profile application resource with GMF editors #34

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Open a GMF-based editor
2. Apply a profile
3. Apply a stereotype
4. Click save in the profile applications view

What is the expected output? What do you see instead?
The profile application should be saved and everything should keep working 
normal. However, the profile application view gets unloaded after saving it. 
The reason is that GMF-based editors have a workspace synchronizer (cf. 
http://download.eclipse.org/modeling/emf/transaction/javadoc/workspace/1.5.0/org
/eclipse/emf/workspace/util/WorkspaceSynchronizer.html) which observes all 
files loaded in its resource set. As the profile application is loaded in the 
editor's resource set, an external save will trigger the synchronizer to handle 
the file update, which is, by default, unloading it.

Temporarily, we may work around this issue by clicking the save button of the 
GMF-based diagram editor instead of the button in the profile application view. 
Saving the diagram will also save the profile application resource, as it will 
save all resources in its resource set.

Original issue reported on code.google.com by p.langer on 27 Mar 2013 at 4:46

GoogleCodeExporter commented 8 years ago
Issue 39 has been merged into this issue.

Original comment by p.langer on 9 Aug 2013 at 8:12

GoogleCodeExporter commented 8 years ago

Original comment by p.langer on 9 Aug 2013 at 8:20

GoogleCodeExporter commented 8 years ago
I just want to give my two cents.

This is not an issue only with GMF editor but all of them (graphiti, 
reflective, ...) that employ workspace synchronizer.

I looked a bit into it and I would suggest to consider this possible solution:
* Load the profile application resource and the model resource in a new 
resource set (not the same resource set of the model's editor). This way the 
editor's workspace synchronizer will not unload profile application resource 
when it registers a change in the resource set.
* Provide synchronization mechanism of your own in order to track the changes 
in the model instance. 

This certainly will give more control. Downside is the implementation of the 
synchronizer and it's integration with the current implementation.

Right now there are no means to deactivate workspace synchronizer of an editor 
when there is a change in a profile application resource. Well, not true, 
overriding the editor's code is possible, but this is not a good solution. 
Actually, it is not a solution at all, at best it is a bad fix. Because an 
editor's workspace synchronizer has a purpose and should not be airily 
deactivated.

Original comment by bec...@gmail.com on 17 Dec 2013 at 12:49