[Papyrus diagram]Explaination needed of Shape (null) / Connector (null) entries in comparison editor [message #1750046] |
Thu, 15 December 2016 12:52 |
|
Occasionally, I got cryptical entries in the comparison editor saying shape(null) / connector (null) added or deleted.
See attached screenshot from Comparison editor:
They seems to be related to stereotype comments or stereotype comment links being added to the diagram (.notation-file) under the hood in some situations. Can the reason be that the applied profile is unavailable/unresolved in some compare/merge scenarios? The profile is in another project but in the same repo.
I can also mention that the comparison of .uml-files works fine. The only issues are with the -notation-files
I need some explanation why this is happening and if there is a way to avoid those cryptical entries. Am I doing something wrong?
I am running the EMF Compare 3.3.0 Integration build on Papyrus 2.0.1/Neon.1
Thanks
Thomas
Thomas Wiman
MetaModelAgent Product Manager
|
|
|
Re: [Papyrus diagram]Explaination needed of Shape (null) / Connector (null) entries in comparison ed [message #1750126 is a reply to message #1750046] |
Fri, 16 December 2016 09:53 |
|
Hi Thomas,
yes, I get those too occasionally. In most of the cases that I've seen, these are mostly invisible shapes / connectors that part of the representation of a certain UML concept; often -- as you say -- related to stereotype comments. They often don't have a direct semantic model element, which is why the label is cryptically called "null". Usually it also doesn't matter whether they are merged or not, since they are invisible and they'd just be re-created the next time you open the diagram.
To address this problem, we need to collect a list of examples in which they appear and analyse when they are added. If they are added each time a certain shape that represents a certain UML concept are added, we have to introduce a customization to group them and handle them as one logical difference (i.e., accepting and rejecting them as a whole). I'm afraid that we'll not be able to put one solution in place that rules them all. I believe we'll have to incrementally handle and customize those case by case.
We also ran into a few cases, where certain notation elements are added at the first time the user, for instance, adds a child to a compartment. But for the second, third, etc. child, they will not be added again. These cases are then often related to styling and layout of the compartment and will be a bit more difficult to handle (simple grouping of differences is not enough, EMF Compare has to know that these additional changes have to be applied whenever one of the children is to be added). We are currently investigating how to solve such a case in Papyrus-RT.
It would be great, if you could create a bug report for this general problem and attach an example repo. If you encounter additional cases, please attach more than one example repo. This way we can collect the cases and investigate how to tackle them case by case.
Thanks and best wishes,
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02927 seconds