Matching in EMF Compare [message #111477] |
Thu, 31 January 2008 19:37 |
Renata Roginsky 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 Im 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 |
|
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 #615361 is a reply to message #111477] |
Fri, 01 February 2008 00:08 |
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.04368 seconds