Why on earth should I use EMF?

Hi guys,

people often ask me why on earth I use EMF in the Mylyn Intent code. Intent has nothing to do with models (at first sight at least), and yet I use EMF everywhere. I think this question is interesting, and shows that a lot of people still don’t see the awesome benefits brought by the use of EMF & the whole Eclipse Modeling Tools.

In this post, I’ll try to briefly list all the benefits and drawbacks of having based Intent on EMF technologies.

1. Storage abstraction: from workspace to database

The first benefits is that, by storing the Intent Document as an EMF model (instead of text), I can use any serialization mechanism provided by EMF. The default behavior (provided by the Intent Workspace Support) is to store the Intent Document as an XMI file in an hidden folder of the Intent Project, but we can do much more:

using the EMF binary serialization would optimize the disk space for free using the CDO technology to serialize the Intent document allows to store it inside a database (MySQL, H2, MongoDB, PostgreSQL…) for free. CDO also provides real-time sharing capabilities (see 5). We could perfectly imagine a JSON-based serialization, so that my Intent Document can be interpreted by any javascript framework (to provide a web-based editor for instance).

2. Synchronize with any technical arfifact (EMF Compare)

One of the key feature of Intent is to be able to compare the technical artifacts referenced inside the Intent Document with their actual state in the workspace. To do so, we have defined a model-based synchronization mechanism: as long as you are able to represent a technical artifact (e.g. a Java or C++ class, a MANIFEST.MF file, or even a bugzilla task) as a model, then it can be handled by Intent.

Then we use the EMF Compare project to compare the Intent Documentation with the Workspace. EMF Compare also provides nicelly integrated UI to display the differences between doc & code:

And, of course, you are able to make interactive merges between the doc & the code.

3. Complete tooling to export the Intent Document (Acceleo)

Another strong benefits brought by the Modeling stack is Acceleo: it provides a nice tooling to define your own generators. So it is pretty straighfoward to write exporters for the Intent documentation: for the time being, there is only an HTML Bootstrap export available, but we are also working on a nice LaTeX/PDF export.

In addition of being easy to write, providing type checking so that you can easily update your generators when your model changes and a first class user experience (completion, refactoring…), the Acceleo modules are easily extensible. So if you are not 100% pleased with the default HTML export and want to customize it, you can easily extend and override the little parts you want to change.

4. Extensible Validation (EMF Validation)

EMF Validation provides extension points and APIs to easily define your own constraints on models, using the langage that seems the most appropriated (OCL, Java…). 

Intent uses this framework to validate in real-time the referenced technical artifacts. So you are able to define custom constraint with richier capabilities than with checkstyle for example: you can plug a custom constraint that says that “Any Java class extending AbstractAcceptanceTest should only contain public methods entitled ‘testScenario<SCENARIO_ID>’”. Any time this constraint is broken, Intent will display validation issues and provide quick-fixes (you can plug  custom quick-fixes by contributing to extension points).

5. Real-time collaboration (CDO)

According to us, Documentation is a social task, that could really benefits from real-time feedbacks and review. Thanks to the real-time notifications provided by CDO, with a CDO-based Intent Repository 2 users can share their doc in real-time. Any time a user saves, the modificaitons are commited on the CDO Repository, and all clients that have an Intent editor opened see the changes in real-time.

How long would it take to write your own server with such capabilities?

6. REST APIs thanks to EMF URIs

Another useful thing is that EMF allows to provide your own URIHandler, so that you can provide REST APIs. In Intent, you can query the information held by the Intent Documentation thanks to URIs:

‘intent:/INTENT_PROJECT’ returns the Intent Document contained in the given project ‘intent:/INTENT_PROJECT/MyJavaClass’ returns the JavaClass represented as a model

So you can see that the keyword here is absraction: abstraction in storage, representation, generation, validation, comparaison… The Eclipse Modeling Stack is full of tools that you can use for free to provide added value to your software. For instance, I could use the new Sirius project to define graphical modelers allowing to visualize graphically and interact with the Intent documentation.

Some drawbacks

If I have to be completely honest, there is still one thing that can be annoying whit EMF, it’s the backward compatibility: if I want Intent 1.0 to be able to work with Intent documents defined in Intent 0.8, I’ll have to write code migrating the old models as instances of the new 1.0 metamodel. It is also the case with CDO.

But this is an issue you would have had even when writing your own serialization mechanism.

Please let me know if you have reaction or question, I’ll be glad to answer!