Community
Participate
Working Groups
Created attachment 244607 [details] Sample VSM One can define custom variables inside a tool. Once the tool has been executed, theses variables seem to be still here. It can be a source of very strange behaviours. I've provided as attachment : - a VSM based on Ecore, - a test project The VSM contains a simple diagram displaying the EClasses for an EPackage. Steps to reproduce : - import the VSM project - launch a runtime - import the test project - open the test project and create a diagram on "first" EPackage => 3 EClasses are displayed on the diagram - use "test" tool. This tool creates a new EClass. This tool also defines a custom variable named "eClassifiers" => the new Eclass is not displayed and the 3 Eclasses in "second" are now displayed. This is because the "eClassifiers" variable has been defined as a list of all EClasses in model, and it was defined before the new EClass was created. The EClass mapping's semantic candidates expression is "[eClassifiers/]". Once the tool has been executed it uses the "eClassifiers" variable, not the "eClassifiers" feature defined in the ecore metamodel. Once the project is closed and reopened, the diagrams are correct. Until the tools are used. NB : "test2" tools reveals the same underlying problem but it doesnt create a new instance. The other Eclasses don't appear on the diagram at once. But if you close and reopen the diagram they now appear.
Created attachment 244608 [details] Test modeling project
Reproduced. We already identified cases where variables can be in conflict with meta-model features (Sirius doc > specifier > Queries > Acceleo). This case is a little bit different since the "Reference name" seems to be correctly set but the creation tool seems to use the eClassifiers variable instead of the feature to create views.
Warning: some modelers (e.g. Capella) rely on custom variables set directly from Java services (and thus invisible from the VSM). Before making this change we should make sure with them that this would not break them (and see if the uses cases they have could be addressed more cleanly directly in Sirius).
