Bugzilla – Full Text Bug Listing
| Summary: | gmf.glue synchronisation problem | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Yijun Yu <y.yu> | ||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jan | ||||
| Version: | unspecified | Flags: | jan:
indigo+
|
||||
| Target Milestone: | M3 | ||||||
| Hardware: | All | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 326280 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
GMF by default uses universally unique identifiers (UUIDs) to refer to elements. That's why changing a name in a plain GMF editor is not a big deal (the UUID stays the same) Things change when it comes to textual languages: You don't want to see technical UUIDs in a textual model. Instead, you refer to elements by their names. Consequently, you have to update all references of an element when its name changes. These references can be local from within the same file or global from other files. That's why changing a name requires a refactoring, as in Java. Name refactoring for Xtext languages is scheduled for Indigo M3. We will revise this ticket in that context. In the GMF example we try to re-serialize only a minimum region of the model text when the model changes. This is fine as long as no cross-references have to be taken into account. We collect all changes to the EMF model, and try to detect a common root element that is being serialized (converted back into text). In your case, the first rename happens after the model is linked, so the linker has already applied a number of changes to the model. Eventually, the common root element of all these changes and your rename is the model's root element. The whole model is serialized and all cross-refs are fine. The second rename changes the renamed entity only, thus leaving the cross-ref untouched. As a workaround, you can always serialize the whole model on change, e.g. by changing the ChangeAggregatorAdapter. Note that this might have a serious impact on performance when dealing with big models. Created attachment 179613 [details]
Alternative ChangeAggregatorAdapter
Thank you for the prompt help. The bug is fixed for me: as far as my model is not too large, I don't realise the performance penalty. In this case I would favor the "correctness" against "potential performance penalty". == BTW, our requirements engineering tool has started to use the recent xtext technology, which greatly simplified our development: http://sead1.open.ac.uk/openre. Thanks! Evaluate in M3 if the Alternative ChangeAggregatorAdapter should become default. Exchanged ChangeAggregatorAdapter with implementation form attachment. Pushed to master. Closing all bugs that were set to RESOLVED before Neon.0 Closing all bugs that were set to RESOLVED before Neon.0 |
Build Identifier: 20100617-1415 I am trying the Xtext Example project for GMF integration. There is a problem in synchronising the GMF diagram back to the xtext model. Reproducible: Always Steps to Reproduce: 1. Initially the following plugins are generated: org.eclipse.xtext.example.gmf.models org.eclipse.xtext.example.gmf org.eclipse.xtext.example.gmf.diagram org.eclipse.xtext.example.gmf.diagram.extensions org.eclipse.xtext.example.gmf.edit org.eclipse.xtext.example.gmf.ui org.eclipse.xtext.gmf.glue 2. Then create a file called a.entities with the following content: entity Object { } entity Abc extends Object { } 3. Initialise the diagram a.entities_diagram 4. rename the Object to Object1 in a.entities_diagram and save it. The entities in the a.entities is updated correctly 5. rename the Object1 to Object2 on the a.entities_diagram and save it. This time the a.entities has an error because the Object1 in the specification of Abc is not updated. 6. There is no error message on the console.