As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
org.eclipse.xtext.xtext.generator.dependencies
, meant to be used in the build.properties
of the DSL project in additional.bundles
; this is meant to replace all the listed dependencies our wizard used to generate for additional.bundles
.additional.bundles
with this single dependency.EcoreUtil2
now provides getAllContentsOfType(Resource, Class)
.CodeMinding
has been corrected to CodeMining
. The wrong string was used to generate the configuration method in the abstract UI module, which is now correct: configureCodeMining
. The wrong string appeared also in the Names.named
for injection. Re-generating the language should update your DSL to the correct version. If you used to manually inject with Names.named("codeMinding")
, you have to manually modify that to Names.named("codeMining")
.Exceptions.addSuppressed
is deprecated now and will be removed with the next Xtext release.The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release).
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.36.0 …
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
The AbstractLinkedEditingIntegrationTest.waitForDisplay()
method has been deprecated in favor of the inherited AbstractWorkbenchTest.waitForEventProcessing()
method. Both methods are doing the same, only the method names are different. For a long term we would like to clean up the duplicated code and completely remove the deprecated method.
The long time deprecated org.eclipse.xtext.junit4
and org.eclipse.xtext.xbase.junit
have been removed.
The projects org.eclipse.xtext.testing
, org.eclipse.xtext.ui.testing
, org.eclipse.xtext.xbase.testing
and org.eclipse.xtext.xbase.ui.testing
already provide replacements for the above deprecated projects.
Note that the old base class AbstractXtextTests
is now part of org.eclipse.xtext.testing
.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release).
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.35.0 …
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
IMPORTANT: before switching to Java 21, make sure to go through the deprecation notice below about org.eclipse.xtext.xbase.lib.IterableExtensions.last(Iterable<T>)
.
In Eclipse, using a recent JDT version, Xbase languages, including Xtend, can access Java 21 generated byte-code and refer to Java records.
For Maven/Tycho builds, e.g., xtext-maven-plugin
and xtend-maven-plugin
, a new version of jdt.core
, e.g., 3.37.0, must be forced (currently, in the BOM, we still use an older version of JDT).
This can be achieved by passing the system property -Djava-21
when running Maven (our BOM will automatically activate the new version of JDT).
Alternatively, you can place the line -Djava-21
in your .mvn/maven.config
file in the root folder.
For Gradle, you need to force the dependency of the new version of jdt.core
, e.g., 3.37.0.
In Xbase languages (including Xtend), multi-line strings (that is, strings that span several lines, NOT Xtend template expressions) are now normalized concerning end-of-line characters, following the same strategies of Normalization Of Line Terminators in Java Text Blocks: Windows CR in the DSL textual sources will not be part of the string in the generated Java code, which will only contain Unix LF.
This change leads to the same Java code generated in Windows and Unix-like systems (see issue https://github.com/eclipse-xtext/xtext/issues/2293).
This DSL string
var s = "a multi
line string"
Will always result in the following generated Java code in Windows, Linux, and macOS:
String s = "a multi\nline string";
While before, in Windows, it would have been:
String s = "a multi\r\nline string";
Note that the behavior for explicit escape sequences (\\r
) will remain the same as before.
The new JvmGenericTypeValidator
was introduced to automatically perform several Java-related checks in the hierarchy of the inferred JvmGenericType
s of an Xbase language, with the corresponding error reporting.
For example, cycles in a hierarchy, extension of a final class, proper extension of an abstract class (do you implement all the abstract methods or declare the inferred class as abstract?), proper method overriding, etc. It also performs duplicate elements checks, like duplicate parameter names, duplicate fields and duplicate methods (keeping the type-erasure into consideration when using types with arguments).
This mechanism assumes that you implement the JvmModelInferrer
“correctly”.
It only checks the first inferred JvmGenericType
for the same DSL element (i.e., if for an element Entity
you infer two JvmGenericType
s, t1
and t2
, only the first one will be checked).
Moreover, it only checks Jvm model elements with an associated source element.
Concerning intended classes to extend and interfaces to extend/implement, it assumes the model inferrer uses the new JvmTypesBuilder#setSuperClass(JvmDeclaredType, JvmTypeReference)
and JvmTypesBuilder#addSuperInterface(JvmDeclaredType, JvmTypeReference)
, respectively.
Currently, this validator must be enabled explicitly through the composedCheck
in the MWE2 file or the @ComposedChecks
annotation in the validator, e.g., @ComposedChecks(validators = JvmGenericTypeValidator.class)
.
The Domainmodel example now uses this validator.
The Xtend validator has been refactored to also use this validator.
When using xtext-maven-plugin
for Xbase languages, relative paths (instead of absolute paths) are now generated in the ._trace
files.
The configuration option writeStorageResources
has been added to xtext-maven-plugin
to write the semantic model, the resource description, and optionally the node model to a ResourceStorage (.bin
files).
See this integration test for an example.
To single-source the configuration of a language that is built with Maven, the configuration options writeClasspathConfiguration
and classpathConfigurationLocation
were added to the xtext-maven-plugin
. If enabled, a property file will be written that contains the classpath information, model directories, output directories and lookup paths that were used for the plugin execution. The properties file contains file hashes that allow to track changed across subsequent runs.
The initial support for language servers that use Xbase languages is part of this release. It’s based on binary Java resources and uses the classpath configuration that’s written by the maven plugin. Thereby, the Xtext language server can be configured such that Xbase language can resolve against class files from the current project. If a Java language server runs in parallel to the Xtext language server, and incrementally produces class files, the changes will be picked up by the Xtext language server.
Low level APIs were added that allow to customizing the node model and the way it is stored on the EMF objects. This enables advanced use cases like unloading the node model for resources that are already fully resolved. The node model can be re-attached on demand for these cases. Curious users may want to configure the DetachableNodeModelFragment
in their mwe2 workflows.
The highly configurable DetachableNodeModelFragment
can be configured in the mwe2 workflow to emit textmate grammar to drive the lexical coloring in LSP clients that do have support for tm-language definitions.
The AbstractFormatterTest
base class has been added to the org.eclipse.xtext.testing
package to provide a convenient way to test the formatter capabilities. The Xtext Domainmodel example project and the Xtend code base have been extended by concrete formatter test cases to demonstrate the usage of this framework class.
The generated InjectorProvider
for runtime tests has been improved to make customizations easier w.r.t. OSGI/Maven environments (see https://github.com/eclipse-xtext/xtext/pull/3042).
The base class AbstractXtextTests
, for “old”-style testing, is now part of org.eclipse.xtext.testing
. (See also the removal notice below.)
Two new methods were added org.eclipse.xtext.xbase.testing.CompilationTestHelper.Result.assertNoErrors()
/assertNoIssues()
for checking whether during the compilation of the input sources errors, respectively, errors or warnings, were detected.
The AbstractContentAssistTest
class has been extended by API methods to provide a convenient way to test proposals from several resources. The StatemachineContentAssistTest
test class of the Xtext Statemachine example project demonstrates the usage of these new API methods.
The method org.eclipse.xtext.xbase.lib.IterableExtensions.last(Iterable<T>)
has been deprecated in favor of the new org.eclipse.xtext.xbase.lib.IterableExtensions.lastOrNull(Iterable<T>)
.
The reason is that Java 21 introduces the getLast
method in a few collection classes.
Xbase will prefer getLast
to our extension method last
to generate Java code when the runtime is Java 21 and the last
extension method is used in an Xbase DSL code, e.g., Xtend.
The problem is that our extension method last
returns null when the collection is empty, while the getLast
method in Java 21 throws a NoSuchElementException
, leading to different semantics.
We encourage everyone to pay attention to such deprecations and switch to the new lastOrNull
, which retains the semantics of last
, before switching to Java 21.
To keep the consistency between IterableExtensions
and IteratorExtensions
we also deprecated last
in the latter and introduced lastOrNull
in IteratorExtensions
.
In the next release, 2.36.0, the long time deprecated org.eclipse.xtext.junit4
and org.eclipse.xtext.xbase.junit
will be removed.
The projects org.eclipse.xtext.testing
, org.eclipse.xtext.ui.testing
, org.eclipse.xtext.xbase.testing
and org.eclipse.xtext.xbase.ui.testing
already provide replacements for the above deprecated projects.
Note that the old base class AbstractXtextTests
is now part of org.eclipse.xtext.testing
.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release).
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.34.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release).
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.33.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
org.eclipse.xtext.generator
and IXtext2EcorePostProcessor
have been removed.The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release).
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.32.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
org.eclipse.xtext.generator
as well as the Xpand/Xtend(1) based metamodel postprocessor are deprecated and marked for removal.The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release.
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.31.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
Xtext is now built from the new Monorepo at https://github.com/eclipse/xtext and built with Maven only. Many thanks to Lorenzo Bettini for the great effort to make this possible.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release.
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.30.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
The minimal version for Eclipse Platform and JDT in manifests were bumped so that they correspond to our minimal tested target platform of Eclipse 2022-03.
The performance of (overloaded) Xbase expressions was enhanced.
We marked Deprecated API more explicit and also added some forRemoval
to them.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release to all repositories except xtext-xtend):
Christian Dietrich (itemis)
Lorenzo Bettini (Università degli Studi di Firenze)
Sebastian Zarnekow (independent)
Elie Richa (AdaCore)
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.29.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
Xtext now supports Java 17 as source and target, too. This requires newer Eclipse platform and JDT versions that do no longer run on Java 8. That’s why the Xtext framework and Xtend compiler require Java 11 as minimal Java version from 2.29 onwards. While we were at it we also bumped the minimal tested Eclipse version to 2022-03 (2.28 was still compatible to and tested against Eclipse Oxygen). Please Note: We did no special treatment for newer Java constructs in Xtend, so what works, works, what does not, does not - the latter being most likely intentional. Please engage by filing bugs or pull requests (see also issue#1982.
The Incremental Standlone Builder is now capable of performing incremental builds. Depending on the changes that happened since the previous compile run, only a subset of the model files need to be processed. Both model and Java file changes as well as class-path changes are taken into account. The feature is opt-in since it might break backwards compatibility for DSLs that use non-default code generation patterns. Incremental builds can also be enabled for the Xtext maven plugin xtext-extras#805.
<plugins>
<plugin>
<groupId>org.eclipse.xtext</groupId>
<artifactId>xtext-maven-plugin</artifactId>
<configuration>
<languages>
<language>
<javaSupport>(true|false)</javaSupport>
<setup>..MyDslStandaloneSetup</setup>
</language>
</languages>
<incrementalXtextBuild>true</incrementalXtextBuild>
</configuration>
<dependencies>
<dependency>
..
</dependency>
</dependencies>
</plugin>
</plugins>
Language server now has a beta version of semantic token support.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release to all repositories except xtext-xtend):
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists:
Xtext 2.28.0 is a maintenance release.
As you might have recognized, the number of people contributing to Xtext on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext is at risk, at least in the current form and as part of the Eclipse Simrel. If you care, please join the discussion in https://github.com/eclipse-xtext/xtext/issues/1721.
org.eclipse.xtext.sdk
feature.The org.eclipse.xtext.sdk
does no longer package the deprecated org.eclipse.xtext.generator
bundle. Please migrate to the new workflow/generator. The old and deprecated generator can still be found in the new org.eclipse.xtext.generator
feature.
The Xtext project is thankful for the dedication of each committer and contributor. This release has been made possible by the following persons (in order of the number of contributed commits to this release to all repositories except xtext-xtend):
Christian Dietrich (itemis)
Ruben Porras
Karsten Thoms (karakun)
Frank Benoit (ETAS)
Hannes Wellmann (IILS mbH)
As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. For further details please refer to the following lists: