Today a new Eclipse version codenamed Kepler was released, with a lot of nice new features, including conflict handling during update, an update user interface for the Marketplace client or various EGit updates (my favorite is the Commit and Push button in the Commit dialog).
About the less visible stuff, in the modeling projects we use, e.g. EMF, Graphiti or Xtext also got some internal updates, resulting in the need to update our projects. As of now, I updated the Xtext Reflective Editor, as a change in EMF 2.9 made it unusable in Kepler.
I often use this tool to debug the Xtext-based parsers that use Xbase and model inferrers, as it displays the generated model using the EMF reflective editors. Version 0.5.5 is a recommended minor update – it works on both newer EMF/Xtext versions, but maintains compatibility with older EMF versions. It is still downloadable from our update site http://eclipse.cubussapiens.hu.
Thanks for all contributors the new, nice features of Kepler (and of course fixes as well). This can become a new platform for new projects for me – the reflective editor update is only the first of them.
Xtext is a great technology. I really mean it. After 15-30 minutes (depending on your previous domain knowledge) you can get a really fancy textual editor, that parses your text into an EMF model. Xbase is even better: you can simply include Java-like expressions into your language, that can be easily translated into pure Java code.
However, while using Xtext I found some minor “paper-cuts”. One of the most problematic of them was the fact that I cannot open my textual models using the Sample Reflective Ecore Model editor, as I get an exception: java.net.MalformedURLException: unknown protocol: java.
A similar exception occurred if I tried to open the files programatically (but without the help of the generated Xtext editor). When I asked in the Eclipse forums how to open Xtext model files programatically, I was answered (btw. very quickly – kudos for that 🙂 ) that a specific ResourceSet implementation is needed that refers to model files and classes available in a Java project.
This gave me the idea to create an Xtext extension that allows opening an EMF tree editor, the Xtext Reflective Tree Editor. The plug-in consists of two parts:
And an Xtext generator fragment, that can be used to generate a new editor extension to the ui project (with the corresponding dependency added to the reflective editor plug-in).
Usage
To use the plug-in, just follow the following simple steps:
Add hu.cubussapiens.xtext.reflectiveeditor as a dependency to your language project.
Extend your editor generation workflow:
Import the generator package: import hu.cubussapiens.xtext.reflectiveeditor.generator.*
Add the new generator fragment at the end of the generator (file.extensions is the list of file extensions defined in the default workflow): fragment = ReflectiveXtextEditorFragment {
fileExtensions = file.extensions
}
Regenerate your language.
Unless the plugin.xml files are updated automatically, you have to copy the newly generated editor extension from the end of the plugin.xml_gen file of the ui plug-in to the plugin.xml file. The simplest way to do this is to select both files, and open the compare editor from the popup menu (Compare with/Each other…), the copy the changes manually.
Finally, open the runtime workbench, and open your textual model files from the popup menu using Open with/«LanguageName» Reflective Editor. The result should be similar to the screenshot below.
The Xtext Reflective Editor
In my case, the editor shows both the domain model generated from the file directly (the Pattern Model element), the inferred JVM model classes (the various JVM Generic Type instances), and also the referred Java classes as external resources (the resources beginning with the java:/ URIs).
Download
If you are interested in the plug-in in action, download it from our update site: http://eclipse.cubussapiens.hu, or take a look at the repository on Github: https://github.com/ujhelyiz/xtext-reflective
Version 0.5.3 is already available, and hopefully works well for all languages.
If you’re developing with EMF it is a common task to separate the model into multiple files along with enabling the user to create crosslinks between them. This works out-of box if the files are located inside the same project. However, in some cases for larger models it is simply not enough. It can be useful to be able to define reusable (and versioned) packets of models and enable the user to define a configuration which determines the imported model packages. Sounds familiar? The same functionality exists in PDE. Maybe it can be reused for non-java purposes.
