Community
Participate
Working Groups
The EMF Compare framework has several extension points for plugging in customizations of the compare/merge experience for the user. Of these, several address concerns of helping users to understand the relationships between changes in the comparison for complex modeling languages (such as UML) and for DSMLs: post-processors, filters, and (at the extreme) diff engines to compute meaningful diffs, dependencies, and conflicts; label providers and tree providers for presentation of content in the compare viewer panes; etc. These kinds of extensions are required in many cases to simplify a complex language representation in more human-friendly terms or to transform a generalized representation of domain-specific concerns (such as by UML profiles) into a structure that is better aligned with the domain concepts. Modeling applications use Façade Models to address these kinds of concerns. It could be useful to enhance the EMF Compare framework's compare/merge process with an ability for client applications to inject façade models that better represent the semantics of the input models in a comparison, to have the façades compared and merged in lieu of those inputs. This would comprise two major parts: * a framework for bi-directional synchronization of façades with their underlying model representations. EMF Compare would rely on this not only for construction of a façade from the comparison input but also for pushing changes to the underlying model when the mergers modify the façade (and for changes coming back to the façade from side-effects in the underlying model) * extension point(s) for Façade Providers to substitute façade objects for the contents of the model resources or elements that are the input of a comparison. Additional extension points would be needed to abstract certain functions such as copying objects in the merge algorithm, to plug in awareness of façades and their relationship to the "real" underlying model elements The anticipated benefits for EMF Compare clients of a façade-based approach include at least: * obviating or easing the implementation of various EMF Compare extensions by provision of a façade on a single extension point * encoding domain-specific semantics in a single implementation of the façade model that can be used in other contexts than EMF Compare Internal design goals for façade-based comparison support include: * optional: the user should be able to disable façade providers if needed, for example because the provider is buggy or there is a reason to work with the raw model * unobtrusive: the performance of compare/merge operations involving models for which no façades are available (the classic mode of operation ) should not be diminished * agnostic: façade models should not have to implement any special protocols to support compare/merge as it is anticipated that it may common for them to be defined independently or by third parties (e.g., MOF metamodels corresponding to UML Profiles). If any peculiar interfaces are required, it must be possible to implement them on a façade's behalf by some adapter mechanism * consistent: the comparison that is enhanced with façades must be internally consistent. Other EMF Compare extensions and processes must all be able to target and work with façades as with any other model implementation
Assigning to myself for work in progress. There is no target date, yet, for completion.
