Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325251

Summary:	[EMF Compare] please move algorithmic classes from internal to visible packages
Product:	[Modeling] EMFCompare	Reporter:	Christian Schneider <christian.schneider>
Component:	Core	Assignee:	EMF Compare <emf.compare-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	christian.schneider, laurent.goubet
Version:	1.1
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Christian Schneider

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

2010-09-14 09:47:56 EDT

I meant 'algorithmic' stuff, not only arithmetic ;-)

Comment 2 Laurent Goubet

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

2011-08-09 07:39:40 EDT

All of our "internal" packages are exported as x-internal, making them "discourage" instead of "restricted".