Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] schema for MatchEngine missing

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] schema for MatchEngine missing

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF Compare] schema for MatchEngine missing [message #89907]

Mon, 16 July 2007 14:39

Hajo Eichler

Messages: 25
Registered: July 2009

Junior Member

Hi,

I have my own metamodel, which has an id feature on any element. So I want to
write my own MatchEngine (and DiffEngine) for comparing instance of the metamodel
with the help of their ids.

I implemented the MatchEngine interface and want to register it via the extension
point. But I found out that the "schema/engine.exsd" file for the MatchEngine is
missing in the org.eclipse.emf.compare.match plugin.

(Also the source code of this plugin is not fully exported - only the src.zip is
there, but no plugin.xml nor model nor schema folder)

Can you please send me the schema file for the MatchEngine?

Thanks & Best regards,
Hajo

Report message to a moderator

Re: [EMF Compare] schema for MatchEngine missing [message #89952 is a reply to message #89907]

Tue, 17 July 2007 10:45

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

Hajo Eichler a écrit :
> Hi,
>
> I have my own metamodel, which has an id feature on any element. So I
> want to write my own MatchEngine (and DiffEngine) for comparing instance
> of the metamodel with the help of their ids.
>
> I implemented the MatchEngine interface and want to register it via the
> extension point. But I found out that the "schema/engine.exsd" file for
> the MatchEngine is missing in the org.eclipse.emf.compare.match plugin.
>
> (Also the source code of this plugin is not fully exported - only the
> src.zip is there, but no plugin.xml nor model nor schema folder)
>
> Can you please send me the schema file for the MatchEngine?
>
> Thanks & Best regards,
> Hajo

Hi,

First of all, I want to say that EMF Compare's generic match engine
already takes into account XMI IDs that could be present in the models
for comparison.

If you're using functional IDs instead of XMI IDs, then you actually
need to implement your own MatchEngine, yet the MatchEngine extension
point isn't considered public API for the moment. You could implement it
locally by checking out org.eclipse.emf.compare and
org.eclipse.emf.compare.match plugins from the CVS repository
dev.eclipse.org/cvsroot/modeling/org.eclipse.emf/org.eclipse .emf.compare/plugins,
but expect it to be broken in the development course until 1.0 is released.

Report message to a moderator

Re: [EMF Compare] schema for MatchEngine missing [message #89986 is a reply to message #89952]

Tue, 17 July 2007 10:43

Hajo Eichler

Messages: 25
Registered: July 2009

Junior Member

This is a multi-part message in MIME format.
--------------010703000806080602080409
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Dear Laurent,

thanks for the hint. I managed to bring in my own MatchEngine.
Regarding to your answer, I also tried the XMI ID version and have two questions:

1) You say that the current implementation of your MatchEngine already checks for
XMI IDs. Is there any configuration, I have to tell the engine to use the XMI IDs?
Using my example it seams that the engine does not use the XMI ID by default:

I have two models x and y (see x.medini and y.medini). Both have two packages
inside, where the sub-package contains 3 Primitive types for each model. The XMI
IDs for these PrimitiveTypes are 1,2,4 for model x and 1,2,3 for model y. But the
difference model says that those elements with id 3 and 4 are matching and I
should rename the element (see screen shot xmi-id-diff.gif).
I would expect 2 difference (one Addition and one Removal).

2) I get two differences, when moving an element in the containment hierarchy.
Therefore I have a second example:

Model a and b: In model a I moved one PrimitiveType instance (XMI ID = 3) up in
the package containment hierarchy. Now the diff tells me 2 things: first the
element has moved and second the relation "the_owner" has also changed.
I would expect to have only one diff displayed since the relation "the_owner" is
the container relationship.

Maybe the explanation is that our containment relation is navigable in both
direction (the_owner <-> the_owned_elements). Do you have any idea?

Thanks & Best regards,
Hajo

Laurent Goubet schrieb:
> Hajo Eichler a

Report message to a moderator

Re: [EMF Compare] schema for MatchEngine missing [message #90090 is a reply to message #89986]

Tue, 17 July 2007 14:49

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

Hajo,

1) I was indeed mistaken, the comparison taking XMI IDs into account has
been a bug fix in the current version and hasn't made its way into RC2.
This is fixed in the current unstable CVS version and will be fixed in
the final 0.7 release.

2) I cannot reproduce this particular error, but it might very well be a
bug. Could you send me your Kernel.ecore metamodel?

Thanks
Laurent

Hajo Eichler a écrit :
> Dear Laurent,
>
> thanks for the hint. I managed to bring in my own MatchEngine.
> Regarding to your answer, I also tried the XMI ID version and have two
> questions:
>
> 1) You say that the current implementation of your MatchEngine already
> checks for XMI IDs. Is there any configuration, I have to tell the
> engine to use the XMI IDs? Using my example it seams that the engine
> does not use the XMI ID by default:
>
> I have two models x and y (see x.medini and y.medini). Both have two
> packages inside, where the sub-package contains 3 Primitive types for
> each model. The XMI IDs for these PrimitiveTypes are 1,2,4 for model x
> and 1,2,3 for model y. But the difference model says that those elements
> with id 3 and 4 are matching and I should rename the element (see screen
> shot xmi-id-diff.gif).
> I would expect 2 difference (one Addition and one Removal).
>
> 2) I get two differences, when moving an element in the containment
> hierarchy. Therefore I have a second example:
>
> Model a and b: In model a I moved one PrimitiveType instance (XMI ID =
> 3) up in the package containment hierarchy. Now the diff tells me 2
> things: first the element has moved and second the relation "the_owner"
> has also changed.
> I would expect to have only one diff displayed since the relation
> "the_owner" is the container relationship.
>
> Maybe the explanation is that our containment relation is navigable in
> both direction (the_owner <-> the_owned_elements). Do you have any idea?
>
> Thanks & Best regards,
> Hajo
>
> Laurent Goubet schrieb:
>> Hajo Eichler a écrit :
>>> Hi,
>>>
>>> I have my own metamodel, which has an id feature on any element. So I
>>> want to write my own MatchEngine (and DiffEngine) for comparing
>>> instance of the metamodel with the help of their ids.
>>>
>>> I implemented the MatchEngine interface and want to register it via
>>> the extension point. But I found out that the "schema/engine.exsd"
>>> file for the MatchEngine is missing in the
>>> org.eclipse.emf.compare.match plugin.
>>>
>>> (Also the source code of this plugin is not fully exported - only the
>>> src.zip is there, but no plugin.xml nor model nor schema folder)
>>>
>>> Can you please send me the schema file for the MatchEngine?
>>>
>>> Thanks & Best regards,
>>> Hajo
>>
>> Hi,
>>
>> First of all, I want to say that EMF Compare's generic match engine
>> already takes into account XMI IDs that could be present in the models
>> for comparison.
>>
>> If you're using functional IDs instead of XMI IDs, then you actually
>> need to implement your own MatchEngine, yet the MatchEngine extension
>> point isn't considered public API for the moment. You could implement
>> it locally by checking out org.eclipse.emf.compare and
>> org.eclipse.emf.compare.match plugins from the CVS repository
>> dev.eclipse.org/cvsroot/modeling/org.eclipse.emf/org.eclipse .emf.compare/plugins,
>> but expect it to be broken in the development course until 1.0 is
>> released.
>
>
> ------------------------------------------------------------ ------------
>
>
> ------------------------------------------------------------ ------------
>
> <?xml version="1.0" encoding="ASCII"?>
> <EUML.Generic.Kernel:UMLPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:EUML.Generic.Kernel="http:///EUML/Generic/Kernel.ecore" xmi:id="_i_JVgDOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgDOkEdySnfBGVGg4Lg" typeCode="Package" name="y">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPackage" xmi:id="_i_JVgjOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgjOkEdySnfBGVGg4Lg" typeCode="Package" name="PrimitiveTypes">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="1" mediniIdentifier="1" name="void"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="2" mediniIdentifier="2" name="Boolean"/>
> 
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="4" mediniIdentifier="4" name="String"/>
> </the_owned_elements>
> </EUML.Generic.Kernel:UMLPackage>
>
>
> ------------------------------------------------------------ ------------
>
> <?xml version="1.0" encoding="ASCII"?>
> <EUML.Generic.Kernel:UMLPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:EUML.Generic.Kernel="http:///EUML/Generic/Kernel.ecore" xmi:id="_i_JVgDOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgDOkEdySnfBGVGg4Lg" typeCode="Package" name="y">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPackage" xmi:id="_i_JVgjOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgjOkEdySnfBGVGg4Lg" typeCode="Package" name="PrimitiveTypes">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="1" mediniIdentifier="1" name="void"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="2" mediniIdentifier="2" name="Boolean"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="3" mediniIdentifier="3" name="Integer"/>
> 
> </the_owned_elements>
> </EUML.Generic.Kernel:UMLPackage>
>
>
> ------------------------------------------------------------ ------------
>
> <?xml version="1.0" encoding="ASCII"?>
> <EUML.Generic.Kernel:UMLPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:EUML.Generic.Kernel="http:///EUML/Generic/Kernel.ecore" xmi:id="_i_JVgDOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgDOkEdySnfBGVGg4Lg" typeCode="Package" name="y">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="3" mediniIdentifier="3" name="Integer"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPackage" xmi:id="_i_JVgjOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgjOkEdySnfBGVGg4Lg" typeCode="Package" name="PrimitiveTypes">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="1" mediniIdentifier="1" name="void"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="2" mediniIdentifier="2" name="Boolean"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="4" mediniIdentifier="4" name="String"/>
> </the_owned_elements>
> </EUML.Generic.Kernel:UMLPackage>
>
>
> ------------------------------------------------------------ ------------
>
> <?xml version="1.0" encoding="ASCII"?>
> <EUML.Generic.Kernel:UMLPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:EUML.Generic.Kernel="http:///EUML/Generic/Kernel.ecore" xmi:id="_i_JVgDOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgDOkEdySnfBGVGg4Lg" typeCode="Package" name="y">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPackage" xmi:id="_i_JVgjOkEdySnfBGVGg4Lg" mediniIdentifier="_i_JVgjOkEdySnfBGVGg4Lg" typeCode="Package" name="PrimitiveTypes">
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="1" mediniIdentifier="1" name="void"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="2" mediniIdentifier="2" name="Boolean"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="3" mediniIdentifier="3" name="Integer"/>
> <the_owned_elements xsi:type="EUML.Generic.Kernel:UMLPrimitiveType" xmi:id="4" mediniIdentifier="4" name="String"/>
> </the_owned_elements>
> </EUML.Generic.Kernel:UMLPackage>
>
>
> ------------------------------------------------------------ ------------
>

Report message to a moderator

Re: [EMF Compare] schema for MatchEngine missing [message #90107 is a reply to message #90090]

Tue, 17 July 2007 14:12

Hajo Eichler

Messages: 25
Registered: July 2009

Junior Member

This is a multi-part message in MIME format.
--------------030607020608000808070504
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Hi Laurent,

1) With my own MatchEngine I do compare the XMI IDs already. So I will await your
release ;-)

2) I cannot send you our whole metamodel, but I made a small example EMF metamodel
with one containment relation, which is navigable in both directions. Using the
models (modelA.medini + modelB.medini) shows the same effect of having two
difference when moving an element in the containment hierarchy. I hope it helps to
reproduce this on your side. (The plug in was made with the eclipse Europa release.)

Best regards,
Hajo

Laurent Goubet schrieb:
> Hajo,
>
> 1) I was indeed mistaken, the comparison taking XMI IDs into account has
> been a bug fix in the current version and hasn't made its way into RC2.
> This is fixed in the current unstable CVS version and will be fixed in
> the final 0.7 release.
>
> 2) I cannot reproduce this particular error, but it might very well be a
> bug. Could you send me your Kernel.ecore metamodel?
>
> Thanks
> Laurent
>
>
> Hajo Eichler a

Report message to a moderator

Re: [EMF Compare] schema for MatchEngine missing [message #90122 is a reply to message #90107]

Tue, 17 July 2007 16:45

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

Thanks, that was indeed a bug which should be fixed in the final 0.7
release.

Laurent

Hajo Eichler a écrit :
> Hi Laurent,
>
> 1) With my own MatchEngine I do compare the XMI IDs already. So I will
> await your release ;-)
>
> 2) I cannot send you our whole metamodel, but I made a small example EMF
> metamodel with one containment relation, which is navigable in both
> directions. Using the models (modelA.medini + modelB.medini) shows the
> same effect of having two difference when moving an element in the
> containment hierarchy. I hope it helps to reproduce this on your side.
> (The plug in was made with the eclipse Europa release.)
>
> Best regards,
> Hajo
>
> Laurent Goubet schrieb:
>> Hajo,
>>
>> 1) I was indeed mistaken, the comparison taking XMI IDs into account
>> has been a bug fix in the current version and hasn't made its way into
>> RC2. This is fixed in the current unstable CVS version and will be
>> fixed in the final 0.7 release.
>>
>> 2) I cannot reproduce this particular error, but it might very well be
>> a bug. Could you send me your Kernel.ecore metamodel?
>>
>> Thanks
>> Laurent
>>
>>
>> Hajo Eichler a écrit :
>>> Dear Laurent,
>>>
>>> thanks for the hint. I managed to bring in my own MatchEngine.
>>> Regarding to your answer, I also tried the XMI ID version and have
>>> two questions:
>>>
>>> 1) You say that the current implementation of your MatchEngine
>>> already checks for XMI IDs. Is there any configuration, I have to
>>> tell the engine to use the XMI IDs? Using my example it seams that
>>> the engine does not use the XMI ID by default:
>>>
>>> I have two models x and y (see x.medini and y.medini). Both have two
>>> packages inside, where the sub-package contains 3 Primitive types for
>>> each model. The XMI IDs for these PrimitiveTypes are 1,2,4 for model
>>> x and 1,2,3 for model y. But the difference model says that those
>>> elements with id 3 and 4 are matching and I should rename the element
>>> (see screen shot xmi-id-diff.gif).
>>> I would expect 2 difference (one Addition and one Removal).
>>>
>>> 2) I get two differences, when moving an element in the containment
>>> hierarchy. Therefore I have a second example:
>>>
>>> Model a and b: In model a I moved one PrimitiveType instance (XMI ID
>>> = 3) up in the package containment hierarchy. Now the diff tells me 2
>>> things: first the element has moved and second the relation
>>> "the_owner" has also changed.
>>> I would expect to have only one diff displayed since the relation
>>> "the_owner" is the container relationship.
>>>
>>> Maybe the explanation is that our containment relation is navigable
>>> in both direction (the_owner <-> the_owned_elements). Do you have any
>>> idea?
>>>
>>> Thanks & Best regards,
>>> Hajo
>>>
>>> Laurent Goubet schrieb:
>>>> Hajo Eichler a écrit :
>>>>> Hi,
>>>>>
>>>>> I have my own metamodel, which has an id feature on any element. So
>>>>> I want to write my own MatchEngine (and DiffEngine) for comparing
>>>>> instance of the metamodel with the help of their ids.
>>>>>
>>>>> I implemented the MatchEngine interface and want to register it via
>>>>> the extension point. But I found out that the "schema/engine.exsd"
>>>>> file for the MatchEngine is missing in the
>>>>> org.eclipse.emf.compare.match plugin.
>>>>>
>>>>> (Also the source code of this plugin is not fully exported - only
>>>>> the src.zip is there, but no plugin.xml nor model nor schema folder)
>>>>>
>>>>> Can you please send me the schema file for the MatchEngine?
>>>>>
>>>>> Thanks & Best regards,
>>>>> Hajo
>>>>
>>>> Hi,
>>>>
>>>> First of all, I want to say that EMF Compare's generic match engine
>>>> already takes into account XMI IDs that could be present in the
>>>> models for comparison.
>>>>
>>>> If you're using functional IDs instead of XMI IDs, then you actually
>>>> need to implement your own MatchEngine, yet the MatchEngine
>>>> extension point isn't considered public API for the moment. You
>>>> could implement it locally by checking out org.eclipse.emf.compare
>>>> and org.eclipse.emf.compare.match plugins from the CVS repository
>>>> dev.eclipse.org/cvsroot/modeling/org.eclipse.emf/org.eclipse .emf.compare/plugins,
>>>> but expect it to be broken in the development course until 1.0 is
>>>> released.

Report message to a moderator