[news.eclipse.technology.emft] Re: [EMF Compare] Change of the Metamodel

[laurent Goubet <laurent.goubet@xxxxxxx>]

Hi Daniel,

Comments inlined below.

Daniel a écrit :
> Hi Compare-team,
>
> How does the EMF Compare framework behave to changes, not only in the 
> model, but also in the Ecore model?
>
> It is possible to compare models with not exactly the same Ecore model.
> That's what the following option is for, right?
> > compareOptions.put( MatchOptions.OPTION_DISTINCT_METAMODELS, new Boolean( 
> true ) );

This option is in to tell EMF Compare not to use a strict metric for 
type equality (ie, don't tell an EClass (Ecore) is different from a 
Class (UML) only by referring to its type). If you changed the names of 
your metaclasses between two versions of the metamodel, you'll indeed 
need to set this to true.

> So if I want to upgrade a customized model to a newer Version (with 
> changes in the model AND a changed Ecore model), would that be possible? 

It is possible ... as long as your old model can be loaded with the new 
metamodel : EMF Compare does not and cannot infer the "old" metamodel 
from a model conform to it. If the changes between the old version of 
the metamodel and the new don't prevent the loading of the "old" model, 
then you're good to go. Otherwise you'll need to migrate your old model 
to conform with the new version of the metamodel (on that note, you can 
compare the old metamodel with the new to determine the changes that 
took place).

Edapt is a proposed eclipse project that could help you with model 
migration. The proposal is here http://www.eclipse.org/proposals/edapt/ 
but I don't know if the actual project has been created. Edapt is the 
evolution of COPE http://cope.in.tum.de/pmwiki.php that also did a good 
job on this.

> Is Emf compare able to merge changes into a model with an other 
> metamodel? Are conflicts between the models and metamodels detected?

EMF Compare can merge differences between models even if their metamodel 
is distinct ... yet again both models must be loadable through EMF and 
this usually mean that both metamodels must be present. And EMF Compare 
only compares what you ask it to : a model cannot be compared with its 
metamodel, the results would be useless (much like there is no use in 
comparing a document with its DTD, comparing two DTD together would make 
sense).

> So I have to load the models with the corresponding classes of the Ecore 
> model it was created from, I can not just load them with the newest 
> version of the Ecore model, right? That would mean, that I have to keep 
> all versions of the Ecore model or rather the generated Code in my 
> project in order to compare models of a changed Ecore model.

It would seem you already knew the answers I'd give you ;). Yes, you 
need to either keep all versions of the metamodel so that the models can 
be loaded or you can migrate the model so that it conforms to the new 
version of the metamodel before comparing.

> Thanks for carifying the case :)
>
> Daniel

Laurent Goubet
Obeo

begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr/";>Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard