Community
Participate
Working Groups
Helios. EMF Compare registers the ecore content type without reference to the Ecore definition of the ecore content type; causing Bug 318118. Consequently when a default editor is opened programmatically (at the back end of the New Ecore file wizard) the editors registered for Ecore's ecore content type are overlooked; Sample Ecore Editor is registered by conten type, not by extension. Tracing ContentTypeMatcher.findContentTypeFor(fileName) that guesses at the cointent type, the code finds an array of two possible content types, the first of which (the EMF Compare content type) is returned and used for subsequent opens. Since the EMF Compare content type does not have the Ecore content type as its base, resolution by content type misses the alternates. Suggestion 1: Eliminate the duplicate ecore and uml content types. Suggestion 2: Define the alternates as sub-content types of the primaries.
We have had way more than our share of issues with content types, and what you describe here is not Helios specific. All of my investigation simply ended up in the platform code with code discarding additional content-types for the files, ignoring all but the first (which can be random IIRC). We won't add parents to the Compare content-type as this was tested before and broke our compatibility with Eclipse 3.3. Granted, we did break the 3.3 compatibility with the latest patch contributions we accepted in EMF Compare 1.1, and it was too late to revert ... yet we will try to restore it with the next release. If we realize it is impossible to restore Europa compatibility, we will consider fixing this.
Surely one of the benefits of EMF Compare being part of the Helios release is that the Helios EMF Compare release need only work with all Helios releases? Operation with any older Eclipse release is very optional. Operation with future Eclipse releases would be nice, but that's mostly a platform problem. I don't think EMF and platform content type usage had stabilised in Eclipse 3.3, so maintaining compatibility with a dinosaur seems misguided, particularly when it breaks the one release combination that matters.
This should already be doable with the current code base, but we can't test this as much as we should. We need to keep this issue in mind and code our extension directly for it during our restructuration effort. Setting as dependent on the restructuration task so that we remember of this.
This no longer holds for EMF Compare 2 and, though do we plan on re-adding a content-type specific to EMF Compare for model comparison, it will not present the same issue : we no longer need to add "ecore" or any other by default in this content-type. Its only purpose will be to add extensions of files that are not described by the ecore content-type.
