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

Bug 321567

Summary:

Corrupted Visual IDs after re-creating gmfgen

Product:

[Modeling] GMF-Tooling

Reporter:

Christian Waniek <chris.waniek>

Component:

Core

Assignee:

Project Inbox <gmp.gmf-tooling-inbox>

Status:

NEW ---

QA Contact:

Severity:

critical

Priority:

CC:

borlander, mistria

Version:

2.3.0

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

321572

Attachments:

Description	Flags
original gmfmap	none
original gmfgen	none
original trace	none
gmfmap with my changes	none
changed gmfgen	none
trace after recreating gmfgen	none

Description Christian Waniek

2010-08-03 05:55:41 EDT

Build Identifier: 

Briefly:
I made changes to a gmfmap-file. I recreated the gmfgen.
=> The VISUAL_IDs of two edit parts (one of them was added due to my changes), mapping to the same metamodel class but to different features, are broken.

I've been extending the UML2Tools. So as metamodel I use the UML2 metamodel from the Eclipse UML2 project. I've been adding a new mapping to the component diagrams gmfmap file (uml::Class instances in feature uml::Component::nestedClassifier should also be visible inside a Component figures content compartment).
But when I re-create the gmfgen file there are two uml::Class mappings (EditParts), becoming mixed up. Originally there is a 'ClassDiagramNotationInnerClassEditPart' with visual id 3013. After re-creating the gmfgen there is a Class6EditPart with visual id 3021, which has the same semantic meaning as ClassDiagramNotationInnerClassEditPart. The newly added Class5EditPart has now the visual id 3013.

This is very annoying because besides there is custom code which relies on the visual ids (this could be changed) I wouldn't be able to open every old component diagram file. In my opinion the trace mechanism should prevent already existing mappings from getting mixed up with newly added mappings. But in this case it doesn't seem to work well.

Because I'm not so deep into GMF I couldn't figure out what's the reason for this behavior or why the trace doesn't work well.

Reproducible: Always

Comment 1 Christian Waniek

2010-08-03 05:56:25 EDT

Created attachment 175750 [details]
original gmfmap

Comment 2 Christian Waniek

2010-08-03 05:56:41 EDT

Created attachment 175751 [details]
original gmfgen

Comment 3 Christian Waniek

2010-08-03 05:57:01 EDT

Created attachment 175752 [details]
original trace

Comment 4 Christian Waniek

2010-08-03 05:57:47 EDT

Created attachment 175753 [details]
gmfmap with my changes

Comment 5 Christian Waniek

2010-08-03 05:58:31 EDT

Created attachment 175754 [details]
changed gmfgen

the gmfgen after having recreated it with my changed gmfmap

Comment 6 Christian Waniek

2010-08-03 05:59:02 EDT

Created attachment 175755 [details]
trace after recreating gmfgen

trace after recreating gmfgen with the changed gmfmap

Comment 7 Mickael Istria

2011-08-08 12:30:35 EDT

Do you use the Experimental SDK with its org.eclipse.gmf.bridge.trace plugin? It should create a .trace file beside of your model when generating code and should preserve VisualIDs.