The Xtext team is proud to announce release version 2.17 of the famous Language Engineering framework. 16 individual contributors have fixed almost 100 issues and 250 pull requests with ~600 commits – and that’s just in 3 months! Xtext 2.17 participates in the Eclipse Simultaneous Release 2019-03 and is still one of the most active projects at Eclipse.
Of course this release has a special focus on Java 11 support. With the previous version, we laid the foundation for Java 11. Full support was not possible at that time, because Xtext builds on top of various frameworks that themselves had to ship being fully enabled for Java 11 before, like Eclipse JDT, Eclipse Tycho, Eclipse EMF, Maven, Gradle, and any plugins used by them. That’s quite a bunch! But now we are happy to have them all together integrated and made ready ourselves to support the latest and greatest Java version.
We are constantly reviewing the technology stack Xtext builds upon. Everything has been updated to the latest release: Eclipse 2019-03, Gradle 5.2.1, Maven 3.6, EMF 2.15, Tycho 1.3, Eclipse MWE 2.10, ASM 7, JDT, Ace Editor 1.3.3, CodeMirror 5.41.0, Orion 17, and some more.
For clients building Xtext-based applications the most noticeable change is a new artifact: A Maven bill of materials (BOM). With help of the BOM, all third-party dependencies that Xtext relies on are managed in one central artifact. Clients do not have to care about specific versions of Eclipse Platform, EMF, Guava, etc. libraries. They just use the BOM for managing these dependencies.
The BOM can be used for Maven and Gradle builds natively. After declaring the usage of the BOM, dependencies can be used without specifying a version. All managed libraries have been tested to work with Xtext.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.xtext</groupId>
<artifactId>xtext-dev-bom</artifactId>
<version>${xtext.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
dependencies {
compile platform("org.eclipse.xtext:xtext-dev-bom:${xtextVersion}")
}
dependencies {
testCompile 'org.junit.jupiter:junit-jupiter-api'
testRuntime 'org.junit.jupiter:junit-jupiter-engine'
}
We have polished all Maven plugins shipped with Xtext. Everything has been updated to the latest Maven API and refactored to use the annotation API internally. All plugins used by the plugins themselves for the build have been updated to their latest recommended version. The usage of deprecated API has been resolved and changed to also use the recommended API now.
Also an internal but for us nonetheless important refactoring was cleaning up the plugins’ integration tests. The test cases have grown wildly over the time, and we also used here the new BOM and recommended patterns, e.g., proper plugin management and consolidation of common code in the integration tests’ parents. This helps us adding more relevant test cases, and it lowers maintenance costs.
The plugins benefit from BOM usage with a slight performance gain, so there's a positive effect on clients, too.
Since its introduction with Xtext 2.14 (Eclipse Photon, June 2018), the new JUnit 5 support API has been kept a restricted API. Clients using these classes experienced access restriction warnings. We now felt that the API is stable enough to open it up as public API.
The New Project Wizard will now default to JUnit 5 for selection of testing support.
A nice and maybe not well known feature of JDT is the definition of favorites for adding static imports. The types considered for importing static methods are configured for Java in Java → Editor → Content Assist → Favorites.
Good news! Xtend does now also evaluates this preference and allows automatically adding static method imports by using its content assist facility. Try it out and use it (also in Java ;-) ).
It was time to clean up some more. Features that are typically no longer used anymore are the Maven archetype to create Android applications and the GWT support bundles org.eclipse.xtend.lib.gwt and org.eclipse.xtext.xbase.lib.gwt. Any objections? Then please get in touch with us and raise your voice! We will listen.
With this release, we participated in all three milestones of the Eclipse Simultaneous Release for the first time. Until now, it is still a surprisingly high effort to get a release shipped. We mainly struggle with flaky tests and the build infrastructure. Unfortunately, this hits us especially on release dates when builds are especially slow. We are not the only project on the machine that is doing release builds at this time.
Slowly our invests in the automation of creating release branches are paying off. With each milestone, the scripts were improved, and we are able to create release branches with a single click. In the best case, this means just waiting several hours for all the builds to complete. But as said, things do not always go smoothly, and failing UI tests (that worked totally fine on the master branch before) force us to retrigger builds, which take hours to complete again, and that several times. Our focus therefore in on making test execution more reliable.
We further plan to participate in the full Eclipse simultaneous release cycle, which means four releases each three months, i.e. three milestones and the final release.
Most of the work happens on code that is not visible to most users. Fixing bugs is always included, and we are fixing several of them with each release. Most of these bugs, users won’t even notice. Xtext can be considered rather stable and mature nowadays.
We have worked quite a lot on the implementation of UI tests, mainly to reduce the risk of flaky tests, which is, as mentioned above, still a sore point. Also, speeding up tests was in focus. The UI tests take the lion's share of our build time. And for each combination of project setup and build configuration the wizard can produce, we have added an integration test. Quite likely, we will dedicate a separate blog post to our testing efforts.
Major effort is also put into build and release engineering tasks. We are preparing to move the build infrastructure to the Common Build Infrastructure (CBI). With Xtext, we were one of the guinea pig projects for that infrastructure. We are still not fully done here and are still struggling with getting our builds, including UI tests, to run under CBI. In the past, the new infrastructure felt unstable like a Jenga tower built by 20 drunk teenagers. Nonetheless, the Eclipse CBI team is very responsive and helpful, and we are working together to get our builds to run reliably on CBI. Again, worth another blog post or more to share our experience.
Everything we need to build Xtext has been updated to its latest state (see “upgrades” section above), and we cleaned up the code base. The number of warnings and of usages of deprecated or restricted APIs has reached a new minimum.
Xtext 2.17 and the technology stack below it is now supporting Java 11 completely. All third-party components have been lifted to their latest states, respectively. Besides that, the technical debt has been reduced by internal refactorings and revised UI tests. The new Maven BOM facilitates the dependency management for Maven and Gradle build configurations and reduces the risk of misconfiguration or build build problems. The release cadence is now fully in sync with the new Eclipse rolling releases.
Do you want to know more? Have a look at the release notes for Xtext & Xtend.