Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Call To Action: Secure the future maintenance of Xtext ( In a nutshell: the future maintenance of Xtext is a risk)
Call To Action: Secure the future maintenance of Xtext [message #1823619] Mon, 30 March 2020 11:46
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14686
Registered: July 2009
Senior Member
Hello Xtext Community,

You might have observed that the number of people actively contributing to Xtext & Xtend has decreased over the recent years. People move on or shift focus. Of course this has implications: Fewer resources mean fewer new features, fewer bugfixes, and reduced community support. On the other hand, the outside world is turning faster: Four Eclipse releases a year, two Java releases, Gradle, Maven, etc. This means that the effort for maintenance and release engineering is increasing at the same time. Building four releases per year including a dozen milestones, adapting to changes in Eclipse Platform, JDT, keeping pace with new Gradle version, changes in new Java Versions etc - all these activities take their toll. Also with the changes in the team structure, fewer and fewer people have the knowledge about the internal workings and the implications of changes inside and outside of Xtext. In a nutshell: the future maintenance of Xtext is a risk.

As there are many people out there using Xtext in their tools and products, this risk has to be mitigated. We are thinking about what can be done to improve the situation. This basically boils down to two things. itemis AG provides a maintenance budget that can be extended by buying support contracts (contact us at for more information or discuss the issue) and/or getting more people involved and contributing. In the past the development and maintenance of Xtext was always a one/two company thing and never a real community effort. So getting interested parties involved in the maintenance process is going to be challenging.

At EclipseCon in Ludwigsburg this year we talked to a number of interested parties about what we can do and came up with these ideas:

  • Make the general maintenance tasks more transparent and document what needs to be done and what has to be done to be part of an Eclipse Release
  • Have an open call (Hangout, ...) to discuss the roadmap, what needs to be done and who can do what on a regularly basis (4-6 weeks)
  • More automation of tasks
  • Avoid duplicate tasks (mid-term, repo merge)
  • Minimize the risk of things breaking (get rid of old xpand generator/dependency, don't make extensive use of Xtend with its tight integration into JDT, ASM etc and also no longer encourage users to use Xtend for everything that Java can do as good or even better nowadays, Xtend is no longer the Java 17 of today)
  • Think about which features are important and which one can be dropped to reduce the effort
  • Think about the release cadence and being part of the Eclipse simultaneous release train.
  • Find maintainers for subcomponents like Gradle support.
  • Find a better chat-like communication platform than Gitter is atm

This is just a first idea. We invite you to bring in your own ideas into the discussion at

Twitter : @chrdietrich
Blog :

[Updated on: Mon, 30 March 2020 12:55] by Moderator

Report message to a moderator

Previous Topic:Embedding Comments in Custom DSL Files
Goto Forum:

Current Time: Mon Jun 17 23:19:31 GMT 2024

Powered by FUDForum. Page generated in 0.03792 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top