Using the JDT compiler in normal Maven builds

The Maven Compiler Plugin can be customized to use a different compiler than Javac. One of the options listed for the compilerId setting is “eclipse“. To use it you will have to add a dependency to the plexus-compiler-eclipse (current version: 1.8.1).


A pitfall here is that the compiler compliance level is not automatically set through the target setting. You have to set also optimize=true. Otherwise Java 1.5 sources won’t compile.

The plexus-compiler-eclipse (version 1.8.1) takes a rather old version of JDT, 3.3.0-v_771. To use another version you will have to deploy a newer version of JDT yourself into your repository and list this dependency before plexus-compiler-eclipse.

Register custom template variable resolver

Xtext allows easily to add code template proposals for your DSL. By default it ships with some built-in variables besides the ones defined by GlobalTemplateVariables. Now I had the requirement to add a template with a proposal for a version number. Normally all unkown variable bindings in a template are resolved to their name within ${} e.g. ${version} will resolve to “version”. But the proposal should be “1.0.0”. Unfortunately this did not work, since the dot character is not allowed in the variable.

To work around this I wanted to add a custom variable named “version” which will resolve in a first step to the static string “1.0.0”.

1. Extend class XtextTemplateContextType

Xtext’s template variable resolvers are contributed in class XtextTemplateContextType, method addDefaultTemplateVariables().

	protected void addDefaultTemplateVariables() {
		addResolver(new GlobalTemplateVariables.WordSelection());
		addResolver(new GlobalTemplateVariables.LineSelection());
		addResolver(new GlobalTemplateVariables.Date());
		addResolver(new GlobalTemplateVariables.Year());
		addResolver(new GlobalTemplateVariables.Time());
		addResolver(new GlobalTemplateVariables.Dollar());
		addResolver(new GlobalTemplateVariables.User());
		addResolver(new GlobalTemplateVariables.Cursor());

In your subclass you can add your own resolver by overriding addDefaultTemplateVariables(). The following snippet shows the specialized class with the custom VersionResolver:

public class MyTemplateContextType extends XtextTemplateContextType {
	static class VersionResolver extends SimpleTemplateVariableResolver {

		/** Name of the variable, value= {@value} */
		public static final String NAME= "version"; //$NON-NLS-1$

		 * Creates a new word selection variable
		public VersionResolver() {
			super(NAME, "Version"); //$NON-NLS-1$
		protected String resolve(TemplateContext context) {
			XtextTemplateContext ctx = (XtextTemplateContext) context;
			return "1.0.0";
		protected boolean isUnambiguous(TemplateContext context) {
			return false;

	protected void addDefaultTemplateVariables() {
		addResolver(new VersionResolver());

If you want that the variable should be editable you have to return false in method isUnambigious().

2. Guice Configuration

To register your custom XtextTemplateContextType override the configure() method of your UI Module and bind class XtextTemplateContextType to your class:

public class MyDslUiModule extends x.y.z.AbstractMyDslUiModule {
	public MyDslUiModule(AbstractUIPlugin plugin) {

	public void configure(Binder binder) {


After this you will get this variable ‘version’ in your template editor:

Note: Just after finishing this article I found that my colleague Alexander Nittka already blogged this article about the topic.