Community
Participate
Working Groups
Created attachment 253818 [details] VSM exposing the self type issue. On Node and Container creation tools: the initial inferred value of var:self for the first model operation should be the same than var:container (See TaskHelper.buildTaskFromModelOperation callers) To reproduce: . expand in ShouldBeValid section . in "Check Node variables types are infered" . ChangeContext var:self . ChangeContext var:self -> add a ChangeContext featureOwnedInteractions (like the var:container) . in "Check variables types with multiple self types" . ChangeContext var:self . ChangeContext var:self -> add a ChangeContext featureOwnedInteractions (like the var:container) . validate the section: the inferred type for self should be Model and not Interaction/Particant with the resulting "no ownedInteractions feature" validation error error. Discovered during validation of Bug 465421
The var:container type computation done in DiagramInterpretedExpressionQuery.getAvailableVariable is correct. The DiagramInterpretedExpressionQuery.getTargetDomainClasses() is not correct at least for the context/self type of NodeCreationDescription/ContainerCreationDescription model operations and also for their precondition. The other tools will have to be checked. See org.eclipse.sirius.diagram.business.api.query.MappingBasedToolDescriptionQuery.getMappings(), the mappings and the extra mapping of the tools are used in the same level to take their domain class, but for the Node/ContainerCreation we want the domain class of the extra mappings (on which the tool is active without any check on the mapping structure) and the domain class of the container/user of the mappings referenced in the tool : the current diagram description or the parent mapping or the mappping which reuse the referenced mappings.
I'm keeping this in 3.1 because it continues the 3.0 theme of "more precise validation of the VSMs", but with reduced priority. It may slip to 4.0 if we can't find time for it.
Moving out of the 4.0 scope for now, along with all the other issues which were there "by default". This does not mean some of these will not be re-integrated at some point, but for now these issues are not part of the roadmap for 4.0. If you feel strongly about this removal from 4.0 and/or are ready to sponsor the corresponding work, feel free to comment.
