Eclipse Xtext: One Grammar, a Full Language Toolchain
Eclipse Xtext™ is a language development framework
At a glance
- What is it?
- Eclipse Xtext is a Java framework for building programming languages and domain-specific languages, generating the parser, linker, compiler or interpreter and the IDE layer together, and it can also expose a language through the Language Server Protocol. It suits teams that would otherwise hand-write a parser and a separate editor plugin.
- Who is it for?
- Xtext fits a team that needs a real language with an editor, not a one-off parser, and that wants a single grammar driving both the Eclipse IDE layer and a Language Server Protocol endpoint for VS Code or Eclipse Che. It is the wrong choice for a small script-like format where a hand-written parser would take an afternoon, or if you want to avoid the Maven and Tycho build machinery entirely.
- Can I use it commercially?
- Yes, with conditions. EPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The grammar is the starting point, not the deliverable
Most parser generators stop at tokens and a syntax tree. Xtext goes further and treats a language definition as the root of a complete toolchain. The framework covers all aspects of a complete language infrastructure, from the parser, over the linker, compiler or interpreter, to full IDE integration for Eclipse and web-based IDEs. That means a team defining a domain-specific language does not only get parsing, it gets the surrounding machinery a language needs to be usable: linking across files, an execution or evaluation path, and an editing experience with completion, validation and navigation. The stated approach is defaults first, with every service able to be tailored. For a group that has never built a language, that matters, because the alternative is not one generator but a stack of them plus an Eclipse plugin written by hand.
Language Server Protocol is the exit from the Eclipse world
The most consequential design choice for adoption is that languages built with Xtext can be integrated into editors that speak the Language Server Protocol, with VS Code and Eclipse Che named as examples. This matters because the Language Server Protocol is a separate contract from the Eclipse plugin APIs. A framework that only produced Eclipse plugins would lock the language into the Eclipse ecosystem. Xtext instead lets the same language definition reach editors outside it, which is the difference between a language tied to one IDE and a language that can be offered to several. The cost of that portability is that the Eclipse integration is the best supported path, and the richer IDE features that rely on Eclipse specifics do not travel to a generic language server client. The framework does not document in the repository readme exactly which features degrade in a language server mode, so that is worth confirming per feature rather than assuming parity.
A repository that is really several build layers
The top level of the repository shows a project with two build systems side by side. The Xtext modules use names such as org.eclipse.xtext.builder, org.eclipse.xtext.builder.standalone, org.eclipse.xtext.ide, org.eclipse.xtext.common.types, org.eclipse.xtext.activities and org.eclipse.xtext.buildship. Then there is a parallel family of org.eclipse.xtend.* modules covering org.eclipse.xtend.core, org.eclipse.xtend.lib, org.eclipse.xtend.lib.macro, org.eclipse.xtend.standalone, org.eclipse.xtend.ide and org.eclipse.xtend.maven.plugin, alongside an org.eclipse.xtend.maven.archetype and an org.eclipse.xtend.maven.parent. Tycho appears too, through org.eclipse.xtend.tycho.tests.parent, and the repository carries an org.eclipse.emf.mwe2.language.sdk.dummy directory, a placeholder for the MWE2 workflow engine used to generate language SDKs. That layout is not incidental. The plain Maven modules build fast, while the Tycho layer builds the actual Eclipse p2 artifacts that end up in an update site.
Getting the source to build with the bundled wrapper
The repository ships the tooling needed to build it without installing anything globally. There is a Maven wrapper, mvnw, with a mvnw.cmd alongside it for Windows, and a .mvn directory holding its configuration, so the Maven version used by the build is fixed by the project rather than by the machine. There are also two shell scripts, full-build.sh and full-deploy.sh, which sit at the root next to the build description in Builds.md. The build itself is driven from a Jenkinsfile with a jenkins directory for pipeline configuration, so the same build runs in continuous integration and on a developer machine.
If you are working in the IDE rather than in a terminal, the repository also carries .project and .settings directories, which are Eclipse workspace metadata, and a file named RUN_ME_before_tests.launch that exists to be run before the test suites. The test packages are numerous and separated by kind: org.eclipse.xtext.builder.tests, org.eclipse.xtext.builder.standalone.tests, org.eclipse.xtext.common.types.tests, org.eclipse.xtend.ide.tests, org.eclipse.xtend.core.tests, org.eclipse.xtend.lib.tests, org.eclipse.xtend.ide.swtbot.tests and org.eclipse.xtend.performance.tests. The swtbot suites drive the user interface, which is a slower and more fragile kind of test than the unit level ones.
Xtend is the language that sits on top of the framework
Xtend is not just an example shipped alongside Xtext; it is the proof that the framework can host a real general-purpose language, and it is where most of the repository volume sits. The org.eclipse.xtend.core module holds the language implementation, org.eclipse.xtend.lib holds the standard library, and org.eclipse.xtend.lib.macro holds the macro layer, which is how Xtend expresses its own source transformations. There is a separate standalone builder for it, org.eclipse.xtend.standalone, and a dedicated IDE module in org.eclipse.xtend.ide with its own test data directory, org.eclipse.xtend.ide.tests.data. The org.eclipse.xtend.doc and org.eclipse.xtext.doc directories hold documentation. For an adopter this is useful signal: a framework that only demonstrated toy grammars would be far less convincing than one that carries a language used by other people. The flip side is that the bulk of the code you will read when learning Xtext is Xtend, not the framework mechanics you need for your own language.
Where to report problems and how releases are tracked
The repository front page is a signpost rather than documentation. It links to all open pull requests, all open issues, issues labelled as good first issues, and open issues for the milestone Release_2.40, which gives a sense of the release train the project works to. The version number in that milestone name is the clearest signal of the project's pace and shape, since it is a two-part version with a patch-like third component, and it implies that upgrades land often enough to require a migration note. Developer documentation is split into three files with distinct jobs: CONTRIBUTING.md covers reporting bugs, setting up a workspace and submitting changes, QUALITY_GUIDELINES.md covers how to craft code changes, commits and pull requests, and Builds.md covers the build infrastructure and the release process. There is also a SECURITY.md and a NOTICE.md, the latter being the usual companion to a licence file. The project is on Gitter and on Eclipse Chat, with the room named after the project on the matrix.eclipse.org server.
EPL-2.0, no tags, and what that means for a dependency
The licence is EPL-2.0, the Eclipse Public License version 2, which is a weak copyleft licence commonly used for Eclipse infrastructure. Compared with a permissive licence it obliges you to make source for modifications to the covered files available, while letting you combine the library with proprietary code in a larger product. That combination is the reason Eclipse projects use this licence, and it is worth checking against your own distribution model before you commit to it. This is a statement of the obligations the licence text sets out, not legal advice.
On maintenance, the repository is not archived and the last push was on 2026-10-19, so the code base is being worked on. What it does not have is GitHub releases. There are no tagged versions to pin, no changelog releases to diff, and no published artefact to install from a package index. That pushes the practical decision onto the build: you either consume the framework from your own build of the repository, or you depend on an Eclipse update site built and signed elsewhere. The open issues filed against milestone Release_2.40 are the best available window into what is about to change.
Editorial conclusion
Xtext fits a team that needs a real language with an editor, not a one-off parser, and that wants a single grammar driving both the Eclipse IDE layer and a Language Server Protocol endpoint for VS Code or Eclipse Che. It is the wrong choice for a small script-like format where a hand-written parser would take an afternoon, or if you want to avoid the Maven and Tycho build machinery entirely. Before committing, build the repository with the bundled mvnw wrapper and confirm the build scripts full-build.sh and full-deploy.sh complete on your machine, since the last push was on 2026-10-19 and the repository publishes no GitHub releases to fall back on.
Frequently asked questions
What does Eclipse Xtext actually generate for my language?
Xtext covers all aspects of a complete language infrastructure, from the parser, over the linker, compiler or interpreter, to IDE integration for Eclipse and web-based IDEs. The services come with defaults that can be tailored.
Can a language built with Xtext be used in VS Code?
Yes. Languages developed with Xtext can be integrated into editors supporting the Language Server Protocol, with VS Code and Eclipse Che given as examples. The Eclipse integration remains the richest path.
What are the build requirements for the Xtext repository?
The repository ships a Maven wrapper named mvnw with a .mvn configuration directory, plus full-build.sh and full-deploy.sh scripts, and the build is driven by a Jenkinsfile with a jenkins directory. A developer can build with the same tooling CI uses.
What licence is Eclipse Xtext released under?
The licence is EPL-2.0. The repository also carries a NOTICE.md file alongside the LICENSE, and a SECURITY.md for reporting security issues.
Is there an Xtend language in the Xtext repository?
Yes. The repository contains org.eclipse.xtend.core, org.eclipse.xtend.lib, org.eclipse.xtend.lib.macro, org.eclipse.xtend.standalone and org.eclipse.xtend.ide modules, plus an org.eclipse.xtend.maven.plugin and an org.eclipse.xtend.maven.archetype.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/eclipse-xtext-xtext)Was this useful?