Using EMF to represent Eclipse 3.x plug-ins

Yesterday was the first day of Eclipse Europe Summit 2010 in Ludwigsburg. The afternoon, I participated to the Eclipse Modeling Symposium organized by Ed Merks and Sven Efftinge. 

The room was crowded: I evaluated more than 150 attendees to this 4 hours session. It has been a very good opportunity to get an overview of how dynamic is the modeling world in Eclipse. There have been 15 presentations about models migration, graphical modelers (even in 3D !), models testing, code generation, documentation generation, new features for textual DSLs, and many other topics… (you can find a summary on the Mäd Meiers' blog).

I really appreciated the Papyrus presentation, especially when Remi Schnekenburger of CEA explained how they have integrated MoDisco to provide customizable navigation through the models ;-)


I also got the chance to give a presentation during this session. This presentation was about using EMF to describe existing plug-ins developed for Eclipse 3.x. The idea is to create models from the main artifacts which compose an existing plug-in: 

• An inventory model (using KDM Source) for the organization of the plugin (folders and files)
• A comprehensive Java model (using MoDisco) from the Java source code
• A specific model to describe the MANIFEST.MF file
• Several XML models (using MoDisco) for the .classpath, .project and plugin.xml files
• Two KDM models for the content of the plugin.properties and build.properties

These models are referenced by a last model which describes the whole plug-in. 

Here, the main benefit of the approach is not to raise the level of abstraction (the classical benefit of Model-Driven Engineering), but to go from an heterogeneous world (with various file formats) to an homogeneous world (EMF models) where you can manipulate all the information by using EMF APIs (and then any EMF compliant tool).


Then, I presented three examples of how this kind of model can be used:

• Quality Analysis: by introspecting the model of the plug-in to check development rules, we can create a model of violations and inject this model into the Eclipse Problem View.

• Refactoring: by transforming the model of the plug-in and then regenerate it, we can adapt an existing Eclipse 3.x plug-in to fit with the E4 compatibility layer.

• Release Engineering: by extracting additional models from the content of update sites, we are experimenting constraints solver to calculate and evaluate possible build configurations and initialize B3 models.

The slides of my presentation are available on Slideshare.

Mia-Software at Eclipse Modeling Symposium 2010

View more presentations from fmadiot.

Today I will try to combine official sessions (to discover what is coming from other projects) and side discussions with persons who are interested in our work (several meetings are already planned about MoDisco and EMF Facet). 


ESE is definitely too short :-(