Remove our custom EditingContextCrossReferenceAdapter #4134
Comments
pcdavid
added a commit
that referenced
this issue
Oct 25, 2024
Bug: #4134 Signed-off-by: Pierre-Charles David <[email protected]>
39 tasks
39 tasks
pcdavid
added a commit
that referenced
this issue
Oct 25, 2024
Bug: #4134 Signed-off-by: Pierre-Charles David <[email protected]>
|
One scenario to validate before we can actually remove our custom adapter is to define multiple View documents with references between them (typically through reused node description), and make sure they are correctly reloaded from scratch (editing domain disposed) with the inter-document references properly resolved. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's not clear what it does (or more precisely, that what it does adds some value compared to EMF's default behavior).
When replacing it with EMF's standard
ECrossReferenceAdapterI don't see any regression (at least all the integration tests pass).Note that even in it's own
EditingContextCrossReferenceAdapterTest, when not installing it intestMoveObjectthe test still passes.It has at least one specific issue (#1400, though I can't reproduce it on master)
Note that we still need to install an
ECrossReferenceAdapterbecauseIncomingTreeDescriptionProviderneeds fast inverse cross references lookup (SysON too).The text was updated successfully, but these errors were encountered: