{"id":346,"date":"2025-02-10T15:45:06","date_gmt":"2025-02-10T15:45:06","guid":{"rendered":"https:\/\/kinori.tech\/blog\/?p=346"},"modified":"2025-02-11T18:07:15","modified_gmt":"2025-02-11T18:07:15","slug":"building-an-xtext-project-with-tycho","status":"publish","type":"post","link":"https:\/\/kinori.tech\/blog\/en\/2025\/02\/10\/building-an-xtext-project-with-tycho\/","title":{"rendered":"Building an Xtext project with Tycho"},"content":{"rendered":"\n

I am fond of IDE<\/a>s. They make my life simpler, mainly because I am not fond of memorizing every thing. Code completion, syntax highlighting, run configurations, automatic code generation… Well, to be honest, ‘automated’ things is where I usually start getting aggravated. Not because they don’t work, but because they usually hide complex configurations and use ‘sensible defaults’ that are strongly opinionated and that blow everything up when you try to do things your way. In today’s post the culprit is Xtext.<\/p>\n\n\n\n

Hiding behind curtain number one<\/h2>\n\n\n\n

There are two Xtext features that do tons of work, and one is particularly heavy on sensible defaults. The first one is the use of Xtend; although to be honest Xtext has tried to distance itself from Xtend as the Java API has made Xtend a bit redundant. The second one is the language generation via MWE2.<\/p>\n\n\n\n

For Xtend, you have not probably realized that Xtend code has to be actually compiled into Java code. You probably have not realized it, because it is automatically <\/em>done by the Xtend editor when you save your code. If curios, go ahead and delete the files in your xtend-gen<\/em> folders. Because it is usually frowned upon to commit generated code, you will happily run your Tycho build just to find out that your build fails, if you are lucky, do to missing classes; if you are out of luck, your build will fail because ‘no tests where found’ and you would spend 2 days looking at your Xtend test, asking why you see the test in your editor and your build refuses to find it. Well, it can’t find any tests because your Xtend test classes have not been compiled.<\/p>\n\n\n\n

For Xtext, you know that every time you change your language you need to run your ‘Generate XXX (yyy) Language Infrastructure’ run configuration. Unless you are using imported ecore metamodels or complex language mixins, you have probably never looked at the MWE2 file that Xtext creates for you. And even if you did, you probably made changes to the parts that do not affect the ‘sensible defaults’ that will ruin your week… OK, I am over reacting.<\/p>\n\n\n\n

So the MWE2 file is responsible for generating the language infrastructure. This means it generates the ECore metamodel for your language, and all the required java classes for your language to work. If curios, go ahead and delete the files in your src-gen<\/em> folders. Again, all those src-gen<\/em> files should not be committed, so your Tycho build will fail do to missing classes. Thus, your Tycho build must run the MWE2 configuration… and here is where the sensible defaults will test your deduction skills.<\/p>\n\n\n\n

Solving the Xtend compilation<\/h2>\n\n\n\n

There are some considerations and assumptions we need to get straight before you understand what we need to do to make it work. First things are simpler for the source bundles than for the tests. I have a feeling that the tycho-source-plugin<\/kbd> has something to do with this; I assume it is responsible for the tweaks I had to do to make the tests work. Second, your test bundles SHOULD ONLY USE xTend sources. If you try to mix java with xtend tests, then you will have another problem in your hands as maven does not like projects with multiple source folders. There is an official guide<\/a> on how to make it work; perhaps you can adapt his post to that scenario.<\/p>\n\n\n\n

In both cases all you need to do is use the Xtend maven plugin. Easy right? Just need to add it to the poms of all the projects that use xtend. I am not a mojo expert, but from the source code of the xtend-maven-plugin<\/kbd>, I think it is designed to work on a per-project basis. If your project is pom-less then you need to add poms to all the projects with xtend sources. In the pom, you need to add the xtend-maven-plugin<\/kbd>. We are setting to paramters in the configuration, the encoding and the output dir. To keep it in sync with Eclipse, we will use the xtend-gen<\/kbd> folder.<\/p>\n\n\n

\n<project>\n  ...\n  <build>\n    ...\n    <pluginManagement>\n      <plugins>\n  <plugin>\n    <groupId>org.eclipse.xtend<\/groupId>\n    <artifactId>xtend-maven-plugin<\/artifactId>\n    <version>${xtext-version}<\/version>\n    <configuration>\n\t  <encoding>${project.build.sourceEncoding}<\/encoding>\n\t  <!-- need to prefix by basedir to generate to currently built module -->\n\t  <outputDirectory>${basedir}\/xtend-gen<\/outputDirectory>\n\t   <\/configuration>\n  <\/plugin>\n  ...\n<\/pre><\/div>\n\n\n
So for the source plugins that, is all there it’s to it. Now for the test plugins…<\/p>\n\n\n\n
First, the xtend-maven-plugin runs during the testCompile<\/kbd> phase for the test plugins. In that phase, maven will look for classes to compile (e.g. xtend) in the testCompileSourceRoots<\/kbd> folder. In a typical Xtext project, that would be your src<\/kbd> folder. So we could add the src<\/kbd> folder to the project’s testCompileSourceRoots<\/kbd>. However, not all projects have sources that need compilation in the src folder, so how can we avoid this? I found a helpful plugin called init-sources-maven-plugin<\/a>. This plugin allows you to add folders to the testCompileSourceRoots<\/kbd> on a per-project basis. Sweet! <\/p>\n\n\n\n
The second part of the tweaks is that we genrated our java test files in the xtend-gen<\/kbd> folder, so we need to tell maven where to find them. Fianaly, we need to make suer that the tycho-compiler-plugin<\/kbd> is called after the xtend files are generated, and that the tycho-surefire-plugin<\/kbd> finds the compiled test classes in the correct location. Additionally, I also cleaned the xtend-gen folder, to make sure remanent classes don’t hide compilation problems. The resulting pom for the TEST projects would be:<\/p>\n\n\n
\n<build>\n  <testSourceDirectory>${project.basedir}\/xtend-gen<\/testSourceDirectory>\n  <plugins>\n    ...\n\t<plugin>\n\t  <groupId>org.eclipse.xtend<\/groupId>\n\t  <artifactId>xtend-maven-plugin<\/artifactId>\n\t  <version>${xtext-version}<\/version>\n\t  <executions>\n\t\t<execution>\n\t\t  <goals>\n\t\t\t<goal>testCompile<\/goal>\n\t\t  <\/goals>\n\t\t<\/execution>\n\t  <\/executions>\n\t  <configuration>\n\t    <encoding>${project.build.sourceEncoding}<\/encoding>\n\t\t  <!-- need to prefix by basedir to generate to currently built module -->\n\t\t  <testOutputDirectory>${basedir}\/xtend-gen<\/testOutputDirectory>\n\t  <\/configuration>\n\t<\/plugin>\n\t<plugin>\n\t  <groupId>io.github.lengors<\/groupId>\n\t  <artifactId>init-sources-maven-plugin<\/artifactId>\n\t  <version>1.0.0<\/version>\n\t\t<executions>\n\t\t  <execution>\n\t\t\t<goals>\n\t\t\t  <goal>init-sources<\/goal>\n\t\t\t<\/goals>\n\t\t\t<configuration>\n\t\t\t  <testCompileSourceRoots>\n\t\t\t\t<testCompileSourceRoot>${project.basedir}\/src<\/testCompileSourceRoot>\n\t\t\t  <\/testCompileSourceRoots>\n\t\t\t<\/configuration>\n\t\t  <\/execution>\n\t\t<\/executions>\n\t<\/plugin>\n    <plugin>\n      <artifactId>maven-clean-plugin<\/artifactId>\n      <version>3.0.0<\/version>\n      <executions>\n          <execution>\n              <id>auto-clean<\/id>\n              <phase>clean<\/phase>\n              <goals>\n                  <goal>clean<\/goal>\n              <\/goals>\n              <configuration>\n                  <filesets>\n                      <fileset>\n                          <directory>${basedir}<\/directory>\n                          <includes>**\/xtend-gen\/**<\/includes>\n                      <\/fileset>\n                  <\/filesets>\n              <\/configuration>\n          <\/execution>\n      <\/executions>\n    <\/plugin>\n    <plugin>\n      <groupId>org.eclipse.tycho<\/groupId>\n      <artifactId>tycho-compiler-plugin<\/artifactId>\n      <version>${tycho.version}<\/version>\n      <executions>\n          <execution>\n            <goals>\n              <goal>testCompile<\/goal>\n            <\/goals>\n          <\/execution>\n        <\/executions>\n    <\/plugin>\n    <plugin>\n      <groupId>org.eclipse.tycho<\/groupId>\n      <artifactId>tycho-surefire-plugin<\/artifactId>\n      <version>${tycho-version}<\/version>\n      <configuration>\n        <testClassesDirectory>target\/test-classes<\/testClassesDirectory>\n      <\/configuration>\n    <\/plugin>\n    ...\n\n<\/pre><\/div>\n\n\n
Solving the Xtext generation<\/h2>\n\n\n\n
TL;DR<\/strong> Execute the MWE2 from Tycho (maven).<\/p>\n\n\n\n
But for this to work, we need a bit more work and some special considerations. First, credit where credit’s due. The Xtext project has a post<\/a> on how to do this (which also includes information about Xtend). However, their guide assumes that you don’t deviate from the ‘sensible defaults’. So this are my considerations, and why the sensible defaults wont work:<\/p>\n\n\n\n
    \n
  1. I want my project to use the ‘standard’ eclipse project layout, which is also required for Tycho pom-less to work. In this layout the bundles\/plugins are in a separate folder than the tests. <\/li>\n\n\n\n
  2. I should still be able to run the MWE2 generator from Eclipse.<\/li>\n<\/ol>\n\n\n\n
    Both require some modifications to the Xtext guide, because the guide assumes that the language bundles reside side-by-side with the tests. <\/p>\n\n\n\n
    Modifying the core language project’s POM<\/h3>\n\n\n\n
    The first is a small modification and addition to the Tycho pom-less structured build layout<\/a>:<\/p>\n\n\n\n