A diffmodel shows the differences between to given instances of the same metamodel. For that reason it has dependencies to the instances and their metamodel.
In our scenario we copied the diff.ecore in our project in the same folder as our metamodel. Just to see how it looks like and to use it in our approache of loading the diffmodel in a oAW-generator-workflow.
For testing we created two simple instances of our metamodel and added a new object to one of them. In this case the diffmodel holds a reference to the new created object and the parent object.
In this scenario you will have no problems in reading the given diffmodel. But when you change a value of an attribute of a existing object in one of the instances it will cause a problem. The diffmodel will have a reference to the feature of the metaobject of this object.
In this case EMF was not able to resolve the type of the feature which is a reference to a metamodelobject of ecore.ecore. Normaly this should not be a problem.After some time of playing around with different scenarios of we found out that the diff.ecore metamodel of the diffmodel uses different ways of pointing to the ecore metamodel.
As you can see from the screenshot the elements of the ecore metamodel is sometimes referenced via NsUri and sometimes via platform:/plugin.This will cause a problem if you have the diff.ecore file in a different location as delivered with the emf-compare plugin. Only for testing we replaced all references to platform:/plugin with the NsUri and we saw that it worked. I don not know why this has been done, but for maintenace it it important not to use your one custom variant of the metamodel.
For that reason we directly referenced to the generated code within the emf-compare plugin via org.eclipse.emf.compare.diff.metamodel.DiffPackage. After that we were finally able to read any diffmodel instance.
