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.
TemporaryFolder, has been added to the bundle org.eclipse.xtext.testing, meant to replace the class TemporaryFolder, now deprecated, in org.eclipse.xtext.xbase.testing. Clients should update to the new class: the deprecated one will be removed in the future.Our project wizard for Maven/Tycho projects now generates this dependency for the exec-maven-plugin configuration for running the MWE2 workflow:
<dependency>
<groupId>org.eclipse.xtext</groupId>
<artifactId>org.eclipse.xtext.xtext.generator.dependencies</artifactId>
<version>${xtextVersion}</version>
</dependency>
to avoid possible problems with EMF/Platform dependencies (e.g., NoSuchMethodError) due to misaligned transitive dependencies.
This replaces the previously generated dependency xtext-antlr-generator, which is included in the new dependency.
For existing projects, we suggest to perform such a change manually.
The org.eclipse.xtext.xtext.generator.dependencies bundle was introduced in the previous release.
IResourcesSetupUtil.waitForJdtIndex, that blocks until the JDT index finishes its indexing. This is now automatically called from waitForBuild, cleanBuild and fullBuild. This new mechanism removed flaky UI tests from our builds.Xtext now requires Java 17 as the minimal Java version and 2024-03 as the minimal target platform.
IResourcesSetupUtil.isAutobuild(boolean) has been deprecated and will be removed in a future release; its parameter was never used. The new method IResourcesSetupUtil.isAutobuild() should be used instead.TargetPlatformUtil and its method setTargetPlatform have been deprecated: with recent versions of Tycho and PDE, they are not needed anymore.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:
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 JvmGenericTypes 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 JvmGenericTypes, 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: