search

ZeligsoftDev / CX4CBDDS

CX4CBDDS component modeling and generation tool
Apache License 2.0
8 stars 5 forks source link

Eclipse Compare fails to pick up the Papyrus ContentMergeViewer when comparing with EGit #501

Open eposse opened 4 months ago

eposse commented 4 months ago

Issue and tracking information

Developer's time Estimated effort to fix (hours):

Developer's Actual time spent on fix (hours)

Issue reporter to provide a detailed description of the issue in the space below

When performing a comparison of two commits in the Git History view provided by EGit, the side-by-side panel meant to show the model from the two commits uses the default EMF Compare ContentMergeViewer, instead of the customized PapyrusTreeContentMerge viewer. This has several consequences:

  1. The view doesn't support the Papyrus-specific functionality
  2. The view's operations might behave differently
  3. Behaviour from EMF Compare that needs to be overridden (like the one causing Issue #443), cannot be overridden.
eposse commented 4 months ago

When doing a comparison or a merge, the Eclipse Compare framework has to decide how to display the elements being compared, and in particular, it has to create viewers for the left hand-side, right hand-side and possibly the common ancestor or origin. This is done on-demand, by trying to find the appropriate "content viewer". This is done by looking for a "content viewer descriptor", which is selected based on the content type. The content viewer descriptors exist in one of several "content registries", associating content types or "extensions" (i.e. file extensions or other symbolic extension names) to descriptors. These are registered via plug-in extension points. Depending on the descriptor, you get the right kind of viewer.

But finding the viewer descriptor, depends on the content type. And the content type depends on the input to the comparison, and this input has three parts: left, right and common ancestor. This will be resources, but they can be stored in different ways. When the comparison is initiated from the Git History View with "Compare to Each Other", the files are stored in commits. But when the comparison is done with "Compare with Workspace Version" or in the "Synchronize View" (launched from the Project Explorer with right-click "Compare with ..." option), one of the sources (typically the left side) is going to be the local workspace. And this makes a difference, because that determines which resources are discovered to determine the content type. In both cases, the content of a .uml file will be a "Model Type", but in order to pick the Papyrus Compare viewer, it has to determine that the "context" is a Papyrus context, which means that the .uml file has a corresponding .di file. When checking the local workspace, it finds it without a problem, but when checking a git commit, it doesn't (unless the .di file is explicitly in the commit). So in the later case, it determines that the content type is a Model Type but not a Papyrus Context Content Type, and therefore it selects the generic EMF Compare viewer descriptor and therefore the generic EMF Compare viewer, instead of the correct Papyrus Compare viewer.

Now, the key thing here is why it doesn't find the .di file when checking the commit? The reason is that the .di file is not in the commit. A component of EMF Compare, called the ModelResolver is responsible for building the "Comparison Scope", the collection of all resources needed for the comparison. And it is this comparison scope the one that is used to determine if the context is a Papyrus context or not. So the issue is that in the case of a git commit, the model resolver doesn't find the .di file.

This means that we might have to make changes to the ModelResolver in order to detect .di files even when they are not in the commit. I do not know if that is possible yet. But the good news is that it is possible to override the ModelResolver via an extension point.