EMF ecore和xsd不同步，如何解决？

Question

My application is using a model base on an xsd that have been converted to an ecore before generation of the java classes. One of my team member modified the .ecore metamodel in a previous version ,one attribute that used to be generated. He modified the attribute name but not the Extended MetaData specifying the element name used for xml persistance.

<eStructuralFeatures xsi:type="ecore:EReference" name="javaDocsAndUserApi" upperBound="-1"
    eType="#//JavaDocsAndUserApi" containment="true" resolveProxies="false">
  <eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
    <details key="kind" value="element"/>
    <details key="name" value="docsAndUserApi"/>
  </eAnnotations>
</eStructuralFeatures>

so we have an attribute name which is javaDocsAndUserApi and the persisted element named docsAndUserApi , and of course if I create change the attribute in the xsd to be named javaDocsAndUserApi , the ecore transformation will generate a metadata name javaDocsAndUserApi as well, which will break compatibility with previously persisted models.

I have looked at xsd authoring guide to find an ecore:som_attribute that would allow me to specify which key to use in the xsd to force the metadata to be named docsAndUserApi during the xsd to ecore transformation but did not find anything. Does anybody have an idea to help me?

Thank you.

Answer 1

Dealing with evolving (meta-) models is not easy after all. It's basically comes down to migrating data from one format (conforming to one Ecore model) into another (conforming to another Ecore model).

You can apply model transformation techniques like ATL and AMW . This allows you to connect (weave) two Ecore (meta-) models (m1 and m2) and automatically generate code that transforms data from format m1 to format m2 and vice versa. (See here for some very interesting research papers on this subject.)

A pragmatic approach might be to manually implement the model transformation using EMF. Since the changes between your models are simple, this shouldn't be too hard to implement.