This week I am in Minneapolis to attend an OMG Technical Meeting.
Today I participated to the
2nd Eclipse & OMG Symposium where I talked about
MoDisco and how we support the specifications defined by
ADM, the OMG task force working on Software Modernization. I presented an example where we use
KDM (Knowledge Discovery Metamodel) and
SMM (Structured Metrics Metamodel) to control the quality of Eclipse plugins.
We wanted to check automatically some rules which are mandatory by the yearly synchroneous release:
- Version number ends with « qualifier »
- Source code must use ICU4J classes
- The project must contain an « about.html » file
- Packages name should start with the plug-in Id
- Plug-in must not contain JARs files
- Plug-in should contain only one « message.properties » and « Message.java » files
We also wanted to check some rules that we had defined internally at Mia-Software:
- “PLUGIN_ID” variable of “Activator.java” should be initialized with the plug-in Id
- Plug-in Id and Project name should be equal
- «Bundle-Vendor» property value of « MANIFEST.MF » should be « %providerName »
- « plugin.properties » should declare a « providerName » property
- «Bundle-Name» property value of « MANIFEST.MF » should be « %pluginName »
- « plugin.properties » should declare a « pluginName » property
Of course, we could have implemented these rules by using the APIs provided by the plugins already provided by Eclipse (org.eclipse.core, org.eclipse.pde, org.eclipse.pde, etc). But all these APIs are not homogeneous, and it is not always easy to find the right API to use. That's why we decided to experiment an other approach.
Our idea is to use these APIs only to create EMF models of the plugin. Then, once the models are created, we can implement the rules by using only EMF APIs.
In our case, we have used MoDisco to create seven EMF models:
- A KDMSource model describing the organization of the plugin project (files and directories)
- A Java model describing the Java source code of the plugin
- A Manifest model to describe the content of the MANIFEST.MF file
- Two XML models to describe the content of the .project and .classpath files
- Two KDMCode models to describe the content of the plugin.properties and the build.properties files
These models contain all the information required to check the rules listed below.
Rather than directly displaying the violations found in an Eclipse plug-in into the Eclipse Problems View, we use an SMM model to represent the result of the analysis. Then, we have developped a generic tool which displays each rule violation contained in this SMM model into the Eclipse Problems View.
The benefit of this approach is that you just have to know EMF APIs to implement the rules, or use any EMF-compliant tool (such as OCL, ATL or QVT). Another benefit is that the result (the SMM model) is independent from how you want to deliver it to the user. Here we have injected the violations into the Eclipse Problem View, but we could have generated an Excel file or populated a tool such as Sonar.
I have still some little things to improve in this plugin, and I'll try to to commit it this summer as a use-case in MoDisco.
Meanwhile, the complete presentation is available on slideshare.
