Bug 483908 - Location of problem decorator on container is not deterministic
Summary: Location of problem decorator on container is not deterministic
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Diagram (show other bugs)
Version: 3.1.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-12-08 09:35 EST by Vincent Richard CLA
Modified: 2017-03-23 05:20 EDT (History)
2 users (show)

See Also:


Attachments
Diagram Snapshot (13.78 KB, image/jpeg)
2015-12-08 09:35 EST, Vincent Richard CLA
no flags Details
Projects to be imported in a dev plateform (206.31 KB, application/zip)
2015-12-08 09:38 EST, Vincent Richard CLA
no flags Details
Projects to be imported in the runtime plateform (2.51 KB, application/zip)
2015-12-08 09:40 EST, Vincent Richard CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Richard CLA 2015-12-08 09:35:48 EST
Created attachment 258508 [details]
Diagram Snapshot

When problems (usually shown in the Problems view) on an EMF model are reported in the Eclipse plateform by other means than Sirius, it is possible to visualize them as decorators in a Sirius diagram by running the diagram validation.

This report describes the case of problem decorators on container representations having vertical stack style sub containers where the target object of the sub containers is the same as the one of the top container.

In such a case, it appears that the location of the decorator is non deterministic. It can be shown on the top level container or on one of the sub level containers.

One would rather expect that the decorator be shown on the top level container for a given entity.


This case is reproduced using Sirius with Xtext, and having a Sirius representation on the Xtext model. Xtext can report problems on the model and Sirius can display the problems as decorators on the containers of the corresponding objects.

Attached to this bug report is a set of projects to be imported in eclipse.

Here are the steps to reproduce using Eclipse Mars :

 - Download the attached ProblemDecorator.zip and MyTest.zip files
 - Launch Eclipse on an empty workspace
 - Open the import existing projects assistant and import the projects from the ProblemDecorator.zip file
 - Create and run a new launch configuration with all workspace and enabled target plugins
 - In the runtime eclipse, import the existing project MyTest from the MyTest.zip file and open the Modeling perspective
 - Open the my.mydsl file and notice the two problems on the lines 2 and 3. 
   These two problems are generated because the org.xtext.example.mydsl.validation.MyDslValidator is working properly.
 - In the Model Explorer, deploy the semantic tree of my.mydsl and open the "new Greetings" representation.
 - Right click on the diagram and select Validate Diagram"

You should now see something similar to the attached snapshot ProblemDecoratorsOnDiagram.jpg, showing the problem decorator on the object "me" at a different location than on the object "him".

Notes :
- This has been reproduced on a Windows machine as well as my Linux machine
- The actual version of Sirius used to reproduce is 3.1.1.201510291439
Comment 1 Vincent Richard CLA 2015-12-08 09:38:07 EST
Created attachment 258510 [details]
Projects to be imported in a dev plateform
Comment 2 Vincent Richard CLA 2015-12-08 09:40:43 EST
Created attachment 258513 [details]
Projects to be imported in the runtime plateform
Comment 3 Maxime Porhel CLA 2015-12-22 10:16:15 EST
I reproduce the issue. 

In case of compartments (V/H stacks), we might check if Region and RegionContainer have the same semantic element and in this case, choose to display decorators on the RegionContainer only.

We might have the same issue with SemanticBasedDecoration described in the VSM.
Comment 4 Laurent Fasani CLA 2017-03-23 05:20:08 EDT
This issue will be handled as part of the new decoration display mechanism handled with https://bugs.eclipse.org/bugs/show_bug.cgi?id=506259

I will let the sirius product leader decide if we keep the ticket candidate for Sirius 3.1.x or 4.1.x maintenance versions.