Using Maven/Tycho, the building and testing of your DSL implementation can be automated, even on a continuous integration server. One of the most common open source continuous integration servers is Jenkins (http://jenkins-ci.org/). This subject is outside the scope of the book; we refer the interested reader to the Jenkins documentation for its installation and use. Once you get familiar with Jenkins, setting up a build job for your Xtext DSL project is really straightforward by relying on the Maven configuration files generated by the Xtext project wizard.
You can use build jobs in Jenkins for your DSL to continuously test your DSL projects when new modifications are committed to the SCM repository as we do for the examples of this book, as briefly described in the next section. You can have nightly jobs that create the p2 repository and make it available on the web; the nightly builds are common to many Eclipse projects, such as Xtext itself.
If your project is open source and hosted on Github, you may want to take a look at Travis (http://travis-ci.org) that allows you to build and test projects hosted on Github. This service is free for open source projects.
Some tutorials related to Maven/Tycho, the building on continuous integration servers such as Jenkins and Travis and the deployment of update sites on free cloud systems, like Sourceforge and Bintray, can be found on my blog: http://www.lorenzobettini.it/.
All the examples DSLs shown in this book are built using Maven/Tycho. Since I have several DSLs and I prefer to have a single headless build procedure to build and test them all, the structure and configuration of Maven projects of the examples of this book is slightly modified. In particular, there is a single shared project for the target platform, so that I do not have to duplicate it for all the DSLs. Similarly, there is a single parent project. The only exceptions are the DSLs created in this chapter, whose structure is not modified.
Furthermore, all the examples in this book are built on a personal Jenkins continuous integration server and on Travis. The examples are maintained in a Git repository on Github, and as soon as a commit is pushed to the remote Git repository, the build on Travis automatically starts. If something goes wrong during the build, Travis will send a notification email.
This allows me to continuously test all the code of the examples, especially when new versions of Xtext come out.