Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF Compare] Visibility of StatisticBasedSimilarityChecker
[EMF Compare] Visibility of StatisticBasedSimilarityChecker [message #699032] Wed, 20 July 2011 17:14 Go to next message
Eclipse UserFriend
Originally posted by:

Hi Guys,

while working on the EMF Compare <-> CDO interoperability, I found an
issue on StatisticBasedSimilarityChecker. The method:

private boolean hasSameUri(EObject obj1, EObject obj2)

when calculated over CDOObjects always return false. That's CDOObject
uri fragment is calculated using its unique identifier, the so called
CDOID. So, if you compare 2 equal models imported in a CDO repository,
the hasSameURI will always return false, and some execution flows on
isSimilar() method won't happen.

In general, it looks like this method returning always false increases
the rate of incorrect matches or false positives. I successfully
implemented an emulated alternative for CDO that improves very much the
match rate. StatisticBasedSimilarityChecker seems to work very well once
thats changed.

So the thing is that I'd like to customize this method with some custom
logic. However, I face two problems:

a) hasSameURI() is private
b) package org.eclipse.emf.compare.match.engine.internal is not exported

are there any chances that we:

1) change hasSameURI visibility to protected
and
2) export org.eclipse.emf.compare.match.engine.internal with
x-internal:=true, so that extenders may be able, but warned that is "at
their own risk"? (to be coherent, other internal packages should be
exported with that flag as well)

I know there are many coders that don't like exporting internal
packages, but I see that as a show stopper for framework evolution
toward client needs. Thats of course my opinion ;)

Cheers,
Víctor.
Re: [EMF Compare] Visibility of StatisticBasedSimilarityChecker [message #699047 is a reply to message #699032] Wed, 20 July 2011 17:25 Go to previous message
Eclipse UserFriend
Originally posted by:

Sorry guys, wrong newsgroup!

Víctor Roldán Betancort escribió:
> Hi Guys,
>
> while working on the EMF Compare <-> CDO interoperability, I found an
> issue on StatisticBasedSimilarityChecker. The method:
>
> private boolean hasSameUri(EObject obj1, EObject obj2)
>
> when calculated over CDOObjects always return false. That's CDOObject
> uri fragment is calculated using its unique identifier, the so called
> CDOID. So, if you compare 2 equal models imported in a CDO repository,
> the hasSameURI will always return false, and some execution flows on
> isSimilar() method won't happen.
>
> In general, it looks like this method returning always false increases
> the rate of incorrect matches or false positives. I successfully
> implemented an emulated alternative for CDO that improves very much the
> match rate. StatisticBasedSimilarityChecker seems to work very well once
> thats changed.
>
> So the thing is that I'd like to customize this method with some custom
> logic. However, I face two problems:
>
> a) hasSameURI() is private
> b) package org.eclipse.emf.compare.match.engine.internal is not exported
>
> are there any chances that we:
>
> 1) change hasSameURI visibility to protected
> and
> 2) export org.eclipse.emf.compare.match.engine.internal with
> x-internal:=true, so that extenders may be able, but warned that is "at
> their own risk"? (to be coherent, other internal packages should be
> exported with that flag as well)
>
> I know there are many coders that don't like exporting internal
> packages, but I see that as a show stopper for framework evolution
> toward client needs. Thats of course my opinion ;)
>
> Cheers,
> Víctor.
Previous Topic:[EMF Compare] Visibility of StatisticBasedSimilarityChecker
Next Topic:moved from null to null
Goto Forum:
  


Current Time: Sat Dec 20 10:37:01 GMT 2014

Powered by FUDForum. Page generated in 0.01760 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software