oAW WorkflowComponent for EMF-Compare in no time

EMF-Compare is a really cool framework to identify differences between EMF based models in no time. Together with two collegues I am currently writing an article to show the main facts and how the results could be used in a MDSD-approach. In our first step we created a class to trigger the Match- and DiffService to have a Diff-Model as a result. After having that, we wanted to use the generator-framework openArchitectureWare to generate a more readable report of the differences. For that reason we used the serialized diffmodel as input for the generator. After playing around with that, we saw that it is annoying to have two different steps. One for the creating the diffmodel and one for generating the report.
The first thing you might think of when you have this use case is creating an ant-script. In our case we wanted to integrate the creating of the diffmodel in the generator-workflow. For that reason we implemented an custom workflow-component.
I was wondering how fast an easy it could be to do that. You only have to extend the Class AbstractEmfWorkflowComponent and fill the method invoke(WorkflowContext ctx, ProgressMonitor monitor,Issues issues). By doing that you could reuse the already done configurations from the workflow. For example the loading of the necessary metamodels and so on .



In our special case we wanted to have special parameters. To do that you only have to have getters and setters for that stuff. After implementing the method checkConfiguration(Issues issues) it was possible to check it the necessary parameters have been passed to the Component.


The next thing that was really cool is that we do not have to persist the diffmodel any more. We only have to pass the result to the modelslot of the Workflow. By doing that the diffmodel could be used by following Components within the Workflow.


As you can see from the screenshot of the Workflow the new Component is now well integrated and no extra step is necessary.

Why it could be a problem to have a copy of a metamodel

Some days ago I had a strange problem by using the diffmodel of EMF-Compare. Together with a college I tried to generate a more readable format out of a diffmodel.

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.

Finally

Puh. I finally decided to start a blog. From now on I will do my best to publish intresting thing around Eclipse and MDSD. I am looking forward to discussions with other people that will read this blog.