Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 325251 - [EMF Compare] please move algorithmic classes from internal to visible packages
Summary: [EMF Compare] please move algorithmic classes from internal to visible packages
Status: CLOSED FIXED
Alias: None
Product: EMFCompare
Classification: Modeling
Component: Core (show other bugs)
Version: 1.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: EMF Compare CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-14 09:44 EDT by Christian Schneider CLA
Modified: 2011-08-09 07:39 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Schneider CLA 2010-09-14 09:44:25 EDT
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
Comment 1 Christian Schneider CLA 2010-09-14 09:47:56 EDT
I meant 'algorithmic' stuff, not only arithmetic ;-)
Comment 2 Laurent Goubet CLA 2011-03-10 09:17:39 EST
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?
Comment 3 Laurent Goubet CLA 2011-08-09 07:39:40 EDT
All of our "internal" packages are exported as x-internal, making them "discourage" instead of "restricted".