Community
Participate
Working Groups
Build Identifier: Dear Cedric et al., after a break I'm back on my project (EMF Compare is its most central pier). I need to customized the default algorithms due to some special use cases. Unfortunately, subclassing is hardly possible as most of the classes are invisible. Additionally most of the methods are declared private. For instance, I want to specialize the StatisticBasedSimilarityChecker, especially the hasSameUri method. (I want to compare only sections of models so e.g. a certain offset at the beginning of the URI should be ignored). As you may know, a similar issue is mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=314535 as I need to customize the merge mechanisms very slightly. This is only possible by copy/pasting the whole sources. Hope, there will be some progress in the future. Best regards, Christian Reproducible: Always
I meant 'algorithmic' stuff, not only arithmetic ;-)
Unfortunately, the similarity metrics that EMF Compare computes are not something we want provided as public API. You can already override GenericMatchEngine#prepareChecker() in order to use your own similarity checks, though we forbid overrides of the generic implementations. What we could do on this notice is to enhance visibility from restricted (compilation error) to discouraged (compilation warning) of these classes (content of the org.eclipse.emf.compare.match.engine.internal package). We would thus still discourage their referencing and extending (which means : we reserve the right to break this "API" at any time without prior notice), but you'd be allowed by the compiler to override and reference them (with a "discouraged access" warning). Would that be sufficient for your use case?
All of our "internal" packages are exported as x-internal, making them "discourage" instead of "restricted".