Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Matching in EMF Compare
Matching in EMF Compare [message #111477] Thu, 31 January 2008 19:37 Go to next message
Renata Roginsky is currently offline Renata RoginskyFriend
Messages: 10
Registered: July 2009
Junior Member
When I remove or change in any way any association in my model, my
elements are not matched any longer. Here is an example.
I take a model and create a copy of it with a different name. In the
copied model I change a class name, a multiplicity of an attribute and
remove an association.
When I use RSM Compare/Merge, I get this delta between two models, which
looks correct (sorry it's a bit long):

Unresolved | Changes related to <<DomainModel>>POCDomain ModelV1<Model>
Unresolved | Add Nominal Currency<Association> to
<<DomainModel>>POCDomain ModelV1<Model>.Packaged Element
Unresolved | Modify <<DomainModel>>POCDomain ModelV1<Model>.Name
from "POCDomain ModelV1" to "POCDomain Model"
Unresolved | Changes related to Instrument<Package>
Unresolved | Add NominalCurrencyNominalCurrency<Property> to
<<identifiable>>InstrumentV1<Class>.Owned Attribute
Unresolved | Modify <<identifiable>>InstrumentV1<Class>.Name
from "InstrumentV1" to "Instrument"
Unresolved | Delete <Literal Unlimited Natural> from Delivery
TypeDelivery Type<Property>.Upper Value
Unresolved | Delete <Literal Integer> from Delivery
TypeDelivery Type<Property>.Lower Value
Unresolved | Changes related to
Instrument<Package>::Instrument High-Level<Diagram>
Unresolved | Add [View]
(<<identifiable>>Instrument<Class>)(<Class>)Nominal Currency<Association>
to Instrument High-Level<Diagram>.Edges
Unresolved | Diagram View
Unresolved | Changes related to Instrument<Package>::Instrument
High-Level<Diagram>
Unresolved | Add [View]
(<<identifiable>>Instrument<Class>)(<Class>)Nominal Currency<Association>
to Instrument High-Level<Diagram>.Edges

When I use EMFCompare my MatchModel for these two models only contains one
match: the Model itself. So in my DiffModel I get one AttributeChange for
the model name (plus all sorts of gmf changes, which I’m not interested
in). It also seems to be inconsistent between different models. For
another model I have, similar changes yield a couple of changes instead of
one. Could you please shed some light? What am I doing wrong? Not sure if
it matters, but my model has a dependency on another model, and some
tracing.

Here is my code (pretty standard I think):

DifferencesServices ds = new DifferencesServices();
Model origModel = getModelFromFile(MODEL_EMX);
Model v1Model = getModelFromFile(MODEL_V1_EMX);
MatchModel match = ds.modelMatch(origModel, v1Model, new
NullProgressMonitor());
DiffMaker dm = new DiffMaker();
DiffModel diffModel = dm.doDiff(match);
Re: Matching in EMF Compare [message #111521 is a reply to message #111477] Fri, 01 February 2008 00:08 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1886
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020507030702000205080104
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Renata,

Before anything, I'd like to mention that bug fixes made on the latest
versions of EMF Compare (0.8) haven't been backported to 0.7, and even
if 0.8 hasn't seen any Release Candidates as yet, it can be considered
way more stable than 0.7 builds are.

That said, the API for diff and match have been recently refactored
(mainly to be more easily understood, details on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216290). Your code will
then be broken if you update : DifferencesServices has been changed for
"GenericMatchEngine" (yet I suggest you use "MatchService#doMatch()",
instead). DiffMaker has also been changed for "GenericDiffEngine" (yet
again, I suggest you use "DiffService#doDiff" instead).

About those GMF differences you don't care about, EMF Compare offers an
API to compare EObject and their content instead of full resources :
"MatchService#doContentMatch()", this should ignore GMF differences if
you pass in the roots of the objects you wish compared.

Could you confirm you still see these problems with the latest
integration build of EMF Compare?

Regards,
Laurent Goubet
Obeo

Renata Roginsky a
Re: Matching in EMF Compare [message #111608 is a reply to message #111521] Fri, 01 February 2008 21:08 Go to previous message
Renata Roginsky is currently offline Renata RoginskyFriend
Messages: 10
Registered: July 2009
Junior Member
Thanks for the response! That was very quick.
We use EMF 2.2, which doesn’t work with the latest EMF Compare. I’m going
to be stuck with EMF Compare 0.7.0 until we can upgrade RSM, which is
unlikely to happen soon (not something I can personally control,
unfortunately). I looked at RSM Compare/Merge
(com.ibm.xtools.comparemerge.emf...). Do you think I might be able to use
it programmatically? If so, is there any way to find documentation? Help
only offers rather empty javadoc for these packages.

Thanks again!
Re: Matching in EMF Compare [message #615361 is a reply to message #111477] Fri, 01 February 2008 00:08 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1886
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020507030702000205080104
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Renata,

Before anything, I'd like to mention that bug fixes made on the latest
versions of EMF Compare (0.8) haven't been backported to 0.7, and even
if 0.8 hasn't seen any Release Candidates as yet, it can be considered
way more stable than 0.7 builds are.

That said, the API for diff and match have been recently refactored
(mainly to be more easily understood, details on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216290). Your code will
then be broken if you update : DifferencesServices has been changed for
"GenericMatchEngine" (yet I suggest you use "MatchService#doMatch()",
instead). DiffMaker has also been changed for "GenericDiffEngine" (yet
again, I suggest you use "DiffService#doDiff" instead).

About those GMF differences you don't care about, EMF Compare offers an
API to compare EObject and their content instead of full resources :
"MatchService#doContentMatch()", this should ignore GMF differences if
you pass in the roots of the objects you wish compared.

Could you confirm you still see these problems with the latest
integration build of EMF Compare?

Regards,
Laurent Goubet
Obeo

Renata Roginsky a
Re: Matching in EMF Compare [message #615369 is a reply to message #111521] Fri, 01 February 2008 21:08 Go to previous message
Renata Roginsky is currently offline Renata RoginskyFriend
Messages: 10
Registered: July 2009
Junior Member
Thanks for the response! That was very quick.
We use EMF 2.2, which doesn’t work with the latest EMF Compare. I’m going
to be stuck with EMF Compare 0.7.0 until we can upgrade RSM, which is
unlikely to happen soon (not something I can personally control,
unfortunately). I looked at RSM Compare/Merge
(com.ibm.xtools.comparemerge.emf...). Do you think I might be able to use
it programmatically? If so, is there any way to find documentation? Help
only offers rather empty javadoc for these packages.

Thanks again!
Previous Topic:[Announce] EMFT SEARCH 0.7.0 I200802011433 is available
Next Topic:[Announce] EMFT SEARCH 0.7.0 I200802011810 is available
Goto Forum:
  


Current Time: Sun Sep 20 05:05:40 GMT 2020

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

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

Back to the top