Repository navigation
Conversation
The implementation creates some elements of implied relationships before the relationship that will own them: feature chains used as implied generals and binding connectors created during transformation. Until they are inserted in the model they have no container and no resource, so library lookup fails silently from them: a detached feature chain gets no general at all instead of Base::things, and transformBindingConnector needs an extra owner parameter to find the library general of a binding connector. VirtualContainer is an adapter recording the model element for which such an element is created. ElementUtil.getEffectiveContainer returns the real container when there is one and the virtual container otherwise, and ElementUtil.getClosestElementInResource walks these effective containers up to an element in a resource. SysMLLibraryUtil.getLibraryElement starts its lookup from that element, so a detached element resolves library types like the element it was created for, and transformBindingConnector no longer takes the owner. Signed-off-by: Arthur Daussy <arthur.daussy@obeo.fr>
seidewitz
changed the title
There was a problem hiding this comment.
I tried merging this, but the update caused a regression, failing the test org.omg.sysml.interactive.tests.NestedResolutionTest.metadataValueThroughDependentImport, which was introduced in PR #825. This has user-visible consequences: spurious validation warnings that binding connection ends don't have compatible types.
It seems that the types of connection ends are not being computed correctly for the implied bindings of metadata feature values. I have not figured out why.
I have done a reverse merge of master into branch ST6RI-977, which then fails the one test. This needs to be fixed before the branch can be merged into master.
I have fix the issue in the commit ST6RI-977 Ignore proxies for virtual containers |
This PR implements a virtual container for elements attached to a model via implicit relationships.
Background
When an implicit relationship is created that targets, e.g., a library element, the target element is owned in it's owned context, such as a library model. However, there are also cases in which the target element of an implicit relationship is to be considered an owned related element of the implicit relationship.
However, since the owning implicit relationship does not actually exist in the abstract syntax tree (unless and until it is specifically inserted into the model), elements it is considered to own do not actually have any container or resource, as far as EMF is concerned. Previously, if such an element was used as the context of a library lookup, this failed silently: a detached feature chain got no implied
generaltype at all, instead ofBase::things, andtransformBindingConnectorneeded an extraownerparameter to find the librarygeneraltype of a binding connector.Changes
VirtualContainer, an adapter recording the source model element of the implied relationship that "owns" the virtually contained element.ElementUtil.getEffectiveContainerto return the real container when there is one and the virtual container otherwise.ElementUtil.getClosestElementInResourceto walk these effective containers up to an element in a resource.SysMLLibraryUtil.getLibraryElementto start its lookup from the closest element resource, so a detached element resolves library types like the element for which it was created, andtransformBindingConnectorno longer needs anownerparameter.