The Xtext generator

Xtext uses the MWE2 DSL to configure the generation of its artifacts; the default generated .mwe2 file already comes with good defaults, thus, for the moment, we will not modify it. However, it is interesting to know that by tweaking this file we can request the Xtext generator to generate support for additional features, as we will see later in this book.

During the MWE2 workflow execution, Xtext will generate artifacts related to the UI editor for your DSL, but most important of all, it will derive an ANTLR specification from the Xtext grammar with all the actions to create the AST while parsing. The classes for the nodes of the AST will be generated using the EMF framework (as explained in the next section).

The generator must be run after every modification to the grammar (the .xtext file). The whole generator infrastructure relies on the Generation Gap Pattern (Vlissides 1996). Indeed, code generators are fine, but when you have to customize the generated code: subsequent generations may overwrite your customizations. The Generation Gap Pattern deals with this problem by separating the code that is generated (and can be overwritten) from the code that you can customize (without the risk of being overwritten). In Xtext the generated code is placed in the source folder src-gen (this holds for all of the three projects); what is inside that source folder should never be modified, since on the next generation it will be overwritten. The programmer can instead safely modify everything in the source folder src. Indeed, on the first generation, Xtext will also generate a few stub classes in the source folder src to help the programmer with a starting point. These classes are never regenerated and can thus safely be edited without the risk of being overwritten by the generator. Some stub classes inherit from default classes from the Xtext library, while other stub classes inherit from classes which are in src-gen.

Most generated stub classes in the src folder are actually Xtend classes; the Xtend programming language will be introduced in the next chapter, thus, for the moment, we will not look at these stub classes.

There is one exception to the previously described generation strategy, which concerns the file plugin.xml (in the runtime and in the UI plug-ins): further Xtext generations will generate the file plugin.xml_gen in the root directory of your projects. It is up to you to check whether something has changed by comparing it with plugin.xml. In that case you should manually merge the differences. This can be easily done by using Eclipse: select the two files, right-click and navigate to Compare With | Each Other..., as illustrated in the following screenshot:

In general, checking the differences between plugin.xml and plugin.xml_gen is only needed either when modifying the .mwe2 file or when using a new version of Xtext (which can introduce new features).

Finally, after running the MWE2 workflow, since the grammar has changed, new EMF classes can be introduced or some existing EMF classes can be modified; thus, it is necessary to restart the other Eclipse instance where you are testing your editor.