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