diff --git a/xtend-website/_posts/releasenotes/2019-12-03-version-2-20-0.md b/xtend-website/_posts/releasenotes/2019-12-03-version-2-20-0.md new file mode 100644 index 00000000000..8148738026d --- /dev/null +++ b/xtend-website/_posts/releasenotes/2019-12-03-version-2-20-0.md @@ -0,0 +1,48 @@ +--- +layout: post +title: Xtend 2.20.0 Release Notes +date: 2019-12-03 +categories: releasenotes +published: true +--- + +Xtend 2.20.0 is mainly a maintenance release with a small number of usability improvements + +## Eclipse Integration + +### New Refactoring: Import Static Method and Import Static Extension Method + +Two refactoring commands have been added which can add as static or static __extension__ import the selected static method call and update all the occurrences in the document. The refactoring commands can be triggered from the `Refactoring > Import Static | Import Static Extension` context menu in the Xtend editor or using `M1+Shift+M` and `M1+Shift+Alt+M` key shortcuts. ([#751](https://github.com/eclipse/xtext-xtend/issues/751)) + +![Refactoring: Import Static Method]({{site.baseurl}}/images/releasenotes/2_20_refactoring_import_static_method.gif){:height="50%" width="50%"} + +### Improved JUnit test case recognition/execution + +The Xtend IDE has been improved to recognize and execute all JUnit test cases (implemented in Xtend) event if the cursor is currently located before/after the test class definition. + +### New Quick Fix: Add JUnit 4 or 5 to the classpath + +A quick fix was added which adds the necessary libraries for JUnit 4 or 5 to the classpath. The quick fix will show on import errors starting with `org.junit.jupiter` (for JUnit 5) or `org.junit` (for JUnit 4). It works both for plug-in projects and regular Java projects. ([#919](https://github.com/eclipse/xtext-xtend/issues/919) + +![Quick Fix: Add JUnit 4 to Classpath]({{site.baseurl}}/images/releasenotes/2_20_quickfix_add_junit4_classpath.gif){:height="50%" width="50%"} +![Quick Fix: Add JUnit 5 to Classpath]({{site.baseurl}}/images/releasenotes/2_20_quickfix_add_junit5_classpath.gif){:height="50%" width="50%"} + +## Credits + +The Xtend Language 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): + +- Christian Dietrich (itemis) +- Sebastian Zarnekow (itemis) +- Karsten Thoms (itemis) +- Tamas Miklossy (itemis) +- Vivien Jovet (TORO Limited) + +## Fixed Issues + +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: + +* [Fixed GitHub issues](https://github.com/search?q=is%3Aissue+milestone%3ARelease_2.20+is%3Aclosed+repo%3Aeclipse%2Fxtext-xtend&type=Issues) + +* [Closed Pull Requests](https://github.com/search?q=is%3Apr+milestone%3ARelease_2.20+is%3Aclosed+repo%3Aeclipse%2Fxtext-xtend&type=Issues) + +* [Fixed Eclipse Bugzilla tickets](https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&classification=Modeling&classification=Tools&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Ckeywords&f0=OP&f1=OP&f3=CP&f4=CP&known_name=Xtext%202.20&list_id=16618269&product=TMF&product=Xtend&query_based_on=Xtext%202.20&query_format=advanced&status_whiteboard=v2.20&status_whiteboard_type=allwordssubstr) diff --git a/xtend-website/documentation/204_activeannotations.md b/xtend-website/documentation/204_activeannotations.md index a0fe79746f5..4b0ba723f78 100644 --- a/xtend-website/documentation/204_activeannotations.md +++ b/xtend-website/documentation/204_activeannotations.md @@ -240,13 +240,13 @@ Therefore, careful testing and debugging of the processor is essential. It is be org.eclipse.xtend org.eclipse.xtend.core - 2.19.0 + 2.20.0 test org.eclipse.xtext org.eclipse.xtext.xbase.testing - 2.19.0 + 2.20.0 test ``` diff --git a/xtend-website/download.md b/xtend-website/download.md index cd5215c42e8..5aad1786088 100644 --- a/xtend-website/download.md +++ b/xtend-website/download.md @@ -52,7 +52,7 @@ If you already have a project, you need to add the Xtend library: org.eclipse.xtend org.eclipse.xtend.lib - 2.19.0 + 2.20.0 ``` @@ -62,7 +62,7 @@ and the Xtend compiler plugin: org.eclipse.xtend xtend-maven-plugin - 2.19.0 + 2.20.0 @@ -84,13 +84,13 @@ Here is a minimal Gradle build script using Xtend: ```groovy plugins { - id "org.xtext.xtend" version "2.0.7" + id "org.xtext.xtend" version "2.0.8" } repositories.jcenter() dependencies { - compile 'org.eclipse.xtend:org.eclipse.xtend.lib:2.19.0' + compile 'org.eclipse.xtend:org.eclipse.xtend.lib:2.20.0' } ``` diff --git a/xtend-website/images/releasenotes/2_20_quickfix_add_junit4_classpath.gif b/xtend-website/images/releasenotes/2_20_quickfix_add_junit4_classpath.gif new file mode 100644 index 00000000000..bf593fe9e0f Binary files /dev/null and b/xtend-website/images/releasenotes/2_20_quickfix_add_junit4_classpath.gif differ diff --git a/xtend-website/images/releasenotes/2_20_quickfix_add_junit5_classpath.gif b/xtend-website/images/releasenotes/2_20_quickfix_add_junit5_classpath.gif new file mode 100644 index 00000000000..71b29569451 Binary files /dev/null and b/xtend-website/images/releasenotes/2_20_quickfix_add_junit5_classpath.gif differ diff --git a/xtend-website/images/releasenotes/2_20_refactoring_import_static_method.gif b/xtend-website/images/releasenotes/2_20_refactoring_import_static_method.gif new file mode 100644 index 00000000000..cfdd84c6c81 Binary files /dev/null and b/xtend-website/images/releasenotes/2_20_refactoring_import_static_method.gif differ diff --git a/xtext-website/_posts/releasenotes/2019-12-03-version-2-20-0.md b/xtext-website/_posts/releasenotes/2019-12-03-version-2-20-0.md new file mode 100644 index 00000000000..b9d27b4c6f3 --- /dev/null +++ b/xtext-website/_posts/releasenotes/2019-12-03-version-2-20-0.md @@ -0,0 +1,74 @@ +--- +layout: post +title: Xtext 2.20.0 Release Notes +date: 2019-12-03 +categories: releasenotes +published: true +--- + +Xtext 2.20.0 is mainly a maintenance release. + +## Eclipse Integration + +### EGit minimal version + +Xtext requires to use EGit 4.1 or newer now. We have removed a workaround that prevented an endless build loop caused by EGit [Bug#474003](https://bugs.eclipse.org/bugs/show_bug.cgi?id=474003). Since we expect that no clients are still using Xtext >= 2.20 together with the ancient EGit version, we felt safe to finally remove this workaround. + +### New Project Wizard / New File Wizard improvements + +The `New Project Wizard` / `New File Wizard` generator fragments have been extended by the `generateToolbarButton` option. Setting this option to `true` adds new project wizard / new file wizard buttons to the toolbar. Furthermore, the New Project Wizard templates provide an API to +register images that can be used in the template descriptions. All these wizard improvements are demonstrated by the Statemachine example shipped by the Xtext framework. + +## Xtext-Web + +The `Xtext-Web Entities Example` provides improved validator and formatter capabilities, such as validating the entity, property and operation names, validating the uniquness of the property/operation definitions as well as properly formatting the defined packages, entities, properties and operations elements. + +## Upgrades + +* The Eclipse Modeling Workflow Engine (MWE2) was updated to version 2.11.1. +* LSP4J is now on version 0.8.1. +* Maven Tycho was updated to version 1.5.1. +* Gradle to version 5.6.x (Should also work with Gradle 6.0.x which we will ship with Xtext 2.21). +* grgit Gradle Plugin 4.0.0 + +## Xtend + +A word on Xtend. Back in 2013 Xtend was the "Java 10 of today" even before Java 8 was out. Meanwhile Java Release cadence has speeded up and many of Xtends features can be achieved with pure Java, too. There is still some areas where Xtend is particularly advanced like Code generation, Unit tests and lambda heavy APIs like JvmModelInferrer and Formatter. For other tasks there is no need to use Xtend. Also the resources we have no longer allow us to keep the head start against Java. And learning Xtend still is a burden for new Xtext users. To reflect this changed situation we have decided to make Java the default in the wizard again (except e.g. the Generator and a few other APIs). You can still decide if you want Java or Xtend in the workflow. + +## Deprecations + +### Old Generator + +With Xtext 2.9 we changed the way Xtext languages are generated to a new generator infrastructure/workflow (`org.eclipse.xtext.xtext.generator`). Until now we still kept the support for the old (Xpand based) workflows and generator (`org.eclipse.xtext.generator`). We also allowed to use old generator fragments in new workflows through `org.eclipse.xtext.generator.adapter.FragmentAdapter`. As we want to stop using old Xpand in Xtext we will drop this support in a future Xtext release. We strongly recommend you to migrate to the new workflow and to get rid of the usages of `FragmentAdapter`. + +### Xtend(1) based IXtext2EcorePostProcessor + +Xtext has basically two methods to work with metamodels. The first on is to infer the metamodel from the Grammar. The second one is to maintain it manually and import it in Xtext. In the past we had actually a third option too: To hook into the inference with a `IXtext2EcorePostProcessor` written in old Xtend(1). We plan to drop this feature in the future and recommend you to switch to a manually maintained metamodel. + +## Credits + +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](https://github.com/eclipse/xtext#repositories) except [xtext-xtend](https://github.com/eclipse/xtext-xtend)): + +- Christian Dietrich (itemis) +- Karsten Thoms (itemis) +- Sebastian Zarnekow (itemis) +- Tamas Miklossy (itemis) +- D. Gabriel (Bachmann) ![](https://img.shields.io/badge/-first%20time%20contributor-green.svg) +- Jan Köhnlein (TypeFox) +- Arne Deutsch (itemis) +- Mathias Rieder ![](https://img.shields.io/badge/-first%20time%20contributor-green.svg) +- Elena Rogleva ![](https://img.shields.io/badge/-first%20time%20contributor-green.svg) +- Mark Christiaens (Sigasi) +- Simeon Andreev (Advantest) ![](https://img.shields.io/badge/-first%20time%20contributor-green.svg) +- Stéphane Galland (Université de Technologie de Belfort) + + +## Fixed Issues + +As in every release cycle we were eagerly hunting down bugs, and reviewed and integrated plenty of contributions. Almost 60 issues and 320 pull requests have made it into this release. For further details please refer to the following lists: + +* [Fixed GitHub issues](https://github.com/search?utf8=%E2%9C%93&q=is%3Aissue+milestone%3ARelease_2.20+is%3Aclosed+repo%3Aeclipse%2Fxtext+repo%3Aeclipse%2Fxtext-core+repo%3Aeclipse%2Fxtext-lib+repo%3Aeclipse%2Fxtext-extras+repo%3Aeclipse%2Fxtext-eclipse+repo%3Aeclipse%2Fxtext-idea+repo%3Aeclipse%2Fxtext-web+repo%3Aeclipse%2Fxtext-maven+repo%3Aeclipse%2Fxtext-xtend&type=Issues&ref=searchresults) + +* [Closed Pull Requests](https://github.com/search?utf8=%E2%9C%93&q=is%3Apr+milestone%3ARelease_2.20+is%3Aclosed+repo%3Aeclipse%2Fxtext+repo%3Aeclipse%2Fxtext-core+repo%3Aeclipse%2Fxtext-lib+repo%3Aeclipse%2Fxtext-extras+repo%3Aeclipse%2Fxtext-eclipse+repo%3Aeclipse%2Fxtext-idea+repo%3Aeclipse%2Fxtext-web+repo%3Aeclipse%2Fxtext-maven+repo%3Aeclipse%2Fxtext-xtend&type=Issues&ref=searchresults) + +* [Fixed Eclipse Bugzilla tickets](https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&classification=Modeling&classification=Tools&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Ckeywords&f0=OP&f1=OP&f3=CP&f4=CP&known_name=Xtext%202.20&list_id=16618269&product=TMF&product=Xtend&query_based_on=Xtext%202.20&query_format=advanced&status_whiteboard=v2.20&status_whiteboard_type=allwordssubstr) diff --git a/xtext-website/documentation/103_domainmodelnextsteps.md b/xtext-website/documentation/103_domainmodelnextsteps.md index 86e128b3f5d..bcd7e33c180 100644 --- a/xtext-website/documentation/103_domainmodelnextsteps.md +++ b/xtext-website/documentation/103_domainmodelnextsteps.md @@ -242,12 +242,12 @@ One of the main advantages of DSLs is the possibility to statically validate dom Locate the class *DomainmodelValidator* in the package *org.example.domainmodel.validation* of the language project. Defining the constraint itself is only a matter of a few lines of code: -```xtend +```java @Check -def void checkNameStartsWithCapital(Entity entity) { - if (!Character.isUpperCase(entity.name.charAt(0))) { +public void checkNameStartsWithCapital(Entity entity) { + if (!Character.isUpperCase(entity.getName().charAt(0))) { warning("Name should start with a capital", - DomainmodelPackage.Literals.TYPE__NAME) + DomainmodelPackage.Literals.TYPE__NAME); } } ``` @@ -256,16 +256,15 @@ Any name for the method will do. The important thing is the [Check]({{site.src.x The second validation rule is straight-forward, too. We traverse the inheritance hierarchy of the *Entity* and look for features with equal names. -```xtend +```java @Check -def void checkFeatureNameIsUnique(Feature f) { - var superEntity = (f.eContainer as Entity).superType - while (superEntity !== null) { - for (other : superEntity.features) { - if (f.name == other.name) { - error("Feature names have to be unique", - DomainmodelPackage.Literals.FEATURE__NAME) - return +public void checkFeatureNameIsUnique(Feature f) { + Entity superEntity = ((Entity) f.eContainer()).getSuperType(); + while (superEntity != null) { + for (Feature other : superEntity.getFeatures()) { + if (Objects.equal(f.getName(), other.getName())) { + error("Feature names have to be unique", DomainmodelPackage.Literals.FEATURE__NAME); + return; } } superEntity = superEntity.getSuperType(); diff --git a/xtext-website/documentation/303_runtime_concepts.md b/xtext-website/documentation/303_runtime_concepts.md index 6ee50215a66..c5f5861f02e 100644 --- a/xtext-website/documentation/303_runtime_concepts.md +++ b/xtext-website/documentation/303_runtime_concepts.md @@ -94,10 +94,10 @@ There are some limitations to the concrete syntax validator which result from th To use concrete syntax validation you can let Guice inject an instance of [IConcreteSyntaxValidator]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/validation/IConcreteSyntaxValidator.java) and use it directly. Furthermore, there is an [adapter]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/validation/impl/ConcreteSyntaxEValidator.java) which allows to use the concrete syntax validator as an [EValidator]({{site.src.emf}}/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EValidator.java). You can, for example, enable it in your runtime module, by adding: -```xtend +```java @SingletonBinding(eager = true) -def Class bindConcreteSyntaxEValidator() { - return ConcreteSyntaxEValidator +public Class bindConcreteSyntaxEValidator() { + return ConcreteSyntaxEValidator.class; } ``` @@ -113,14 +113,14 @@ The Check annotation has a parameter that can be used to declare when a check sh All in all this is very similar to how JUnit works. Here is an example written in Xtend: -```xtend -class DomainmodelValidator extends AbstractDomainmodelValidator { +```java +public class DomainmodelValidator extends AbstractDomainmodelValidator { @Check - def void checkNameStartsWithCapital(Entity entity) { - if (!Character.isUpperCase(entity.name.charAt(0))) { + public void checkNameStartsWithCapital(Entity entity) { + if (!Character.isUpperCase(entity.getName().charAt(0))) { warning("Name should start with a capital", - DomainmodelPackage.Literals.TYPE__NAME) + DomainmodelPackage.Literals.TYPE__NAME); } } } @@ -128,18 +128,21 @@ class DomainmodelValidator extends AbstractDomainmodelValidator { You can use the [IResourceValidator]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/validation/IResourceValidator.java) to validate a given resource programmatically. Example: -```xtend -@Inject IResourceValidator resourceValidator +```java +@Inject IResourceValidator resourceValidator; -def void checkResource(Resource resource) { - val issues = resourceValidator.validate(resource, - CheckMode.ALL, CancelIndicator.NullImpl) - for (issue: issues) { - switch issue.severity { +public void checkResource(Resource resource) { + List issues = resourceValidator.validate(resource, + CheckMode.ALL, CancelIndicator.NullImpl); + for (Issue issue: issues) { + switch (issue.getSeverity()) { case ERROR: - println("ERROR: " + issue.message) + System.out.println("ERROR: " + issue.getMessage()); + break; case WARNING: - println("WARNING: " + issue.message) + System.out.println("WARNING: " + issue.getMessage()); + break; + default: // do nothing } } } @@ -230,20 +233,22 @@ Element: ``` -If you want to define the scope for the *superElement* cross-reference, the following Xtend code is one way to go. +If you want to define the scope for the *superElement* cross-reference, the following Java code is one way to go. -```xtend -override getScope(EObject context, EReference reference) { + +```java +@Override +public IScope getScope(EObject context, EReference reference) { // We want to define the Scope for the Element's superElement cross-reference if (context instanceof Element && reference == MyDslPackage.Literals.ELEMENT__SUPER_ELEMENT) { // Collect a list of candidates by going through the model // EcoreUtil2 provides useful functionality to do that // For example searching for all elements within the root Object's tree - val rootElement = EcoreUtil2.getRootContainer(context) - val candidates = EcoreUtil2.getAllContentsOfType(rootElement, Element) + EObject rootElement = EcoreUtil2.getRootContainer(context); + List candidates = EcoreUtil2.getAllContentsOfType(rootElement, Element.class); // Create IEObjectDescriptions and puts them into an IScope instance - return Scopes.scopeFor(candidates) + return Scopes.scopeFor(candidates); } return super.getScope(context, reference); } @@ -255,18 +260,20 @@ The [MapBasedScope]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xt Coming back to our example, one possible scenario for the FilteringScope could be to exclude the context element from the list of candidates as it should not be a super-element of itself. -```xtend -override getScope(EObject context, EReference reference) { - if (context instanceof Element - && reference == MyDslPackage.Literals.ELEMENT__SUPER_ELEMENT) { - val rootElement = EcoreUtil2.getRootContainer(context) - val candidates = EcoreUtil2.getAllContentsOfType(rootElement, Element) - val existingScope = Scopes.scopeFor(candidates) - // Scope that filters out the context element from the candidates list - return new FilteringScope(existingScope, [getEObjectOrProxy != context]) + +```java + @Override + public IScope getScope(EObject context, EReference reference) { + if (context instanceof Element + && reference == MyDslPackage.Literals.ELEMENT__SUPER_ELEMENT) { + EObject rootElement = EcoreUtil2.getRootContainer(context); + List candidates = EcoreUtil2.getAllContentsOfType(rootElement, Element.class); + IScope existingScope = Scopes.scopeFor(candidates); + // Scope that filters out the context element from the candidates list + return new FilteringScope(existingScope, (e) -> !Objects.equal(e.getEObjectOrProxy(), context)); + } + return super.getScope(context, reference); } - return super.getScope(context, reference); -} ``` ### Global Scopes and Resource Descriptions {#global-scopes} @@ -363,17 +370,17 @@ So for an element to be referable, its resource must be on the class path of the As this strategy allows to reuse a lot of nice Java things like jars, OSGi, maven, etc. it is part of the default: You should not have to reconfigure anything to make it work. Nevertheless, if you messed something up, make sure you bind -```xtend -def Class bindIContainer$Manager() { - return StateBasedContainerManager +```java +public Class bindIContainer$Manager() { + return StateBasedContainerManager.class; } ``` in the runtime module and -```xtend -def Provider provideIAllContainersState() { - return org.eclipse.xtext.ui.shared.Access.getJavaProjectsState() +```java +public Provider provideIAllContainersState() { + return org.eclipse.xtext.ui.shared.Access.getJavaProjectsState(); } ``` @@ -385,9 +392,9 @@ If the class path based mechanism doesn't work for your case, Xtext offers an al In this case, your runtime module should use the StateBasedContainerManager as shown above and the Eclipse UI module should bind -```xtend -def Provider provideIAllContainersState() { - return org.eclipse.xtext.ui.shared.Access.getWorkspaceProjectsState() +```java +public Provider provideIAllContainersState() { + return org.eclipse.xtext.ui.shared.Access.getWorkspaceProjectsState(); } ``` @@ -494,18 +501,18 @@ package bar { Value converters are registered to convert the parsed text into a data type instance and vice versa. The primary hook is the [IValueConverterService]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/conversion/IValueConverterService.java) and the concrete implementation can be registered via the runtime [Guice module](302_configuration.html#guicemodules). Simply override the corresponding binding in your runtime module like shown in this example: -```xtend -override Class bindIValueConverterService() { - return MySpecialValueConverterService +```java +public Class bindIValueConverterService() { + return MySpecialValueConverterService.class; } ``` The easiest way to register additional value converters is to make use of [AbstractDeclarativeValueConverterService]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/conversion/impl/AbstractDeclarativeValueConverterService.java), which allows to declaratively register an [IValueConverter]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/conversion/IValueConverter.java) by means of an annotated method. -```xtend +```java @ValueConverter(rule = "MyRuleName") -def IValueConverter getMyRuleNameConverter() { - return new MyValueConverterImplementation() +public IValueConverter getMyRuleNameConverter() { + return new MyValueConverterImplementation(); } ``` @@ -697,11 +704,12 @@ In the Eclipse UI scenario, when there is a workspace, users will expect the enc Unless you want to enforce a uniform encoding for all models of your language, we advise to override the runtime service only. It is bound in the runtime module using the binding annotation [@Runtime]({{site.src.xtext_core}}/org.eclipse.xtext/src/org/eclipse/xtext/service/DispatchingProvider.java): -```xtend -override configureRuntimeEncodingProvider(Binder binder) { - binder.bind(IEncodingProvider) - .annotatedWith(DispatchingProvider.Runtime) - .to(MyEncodingProvider) +```java +@Override +public void configureRuntimeEncodingProvider(Binder binder) { + binder.bind(IEncodingProvider.class) + .annotatedWith(DispatchingProvider.Runtime.class) + .to(MyEncodingProvider.class); } ``` @@ -815,18 +823,19 @@ If in addition to the main language your tests require using other languages for As the default generated [IInjectorProvider]({{site.src.xtext_core}}/org.eclipse.xtext.testing/src/org/eclipse/xtext/testing/IInjectorProvider.java) of your main language (e.g. DomainmodelInjectorProvider) does not know about any other dependent languages, they must be initialized explicitly. The recommended pattern for this is to create a new subclass of the generated *MyLanguageInjectorProvider* in your *\*.test* project and make sure the dependent language is intizialized properly. Then you can use this new injector provider instead of the original one in your test's *@InjectWith*: -```xtend -class MyLanguageWithDependenciesInjectorProvider extends MyLanguageInjectorProvider { - override internalCreateInjector() { - MyOtherLangLanguageStandaloneSetup.doSetup - return super.internalCreateInjector +```java +public class MyLanguageWithDependenciesInjectorProvider extends MyLanguageInjectorProvider { + @Override + protected Injector internalCreateInjector() { + MyOtherLangLanguageStandaloneSetup.doSetup(); + return super.internalCreateInjector(); } } -// @RunWith(XtextRunner) // JUnit 4 -@ExtendWith(InjectionExtension) // JUnit 5 -@InjectWith(MyLanguageWithDependenciesInjectorProvider) -class YourTest { +// @RunWith(XtextRunner.class) // JUnit 4 +@ExtendWith(InjectionExtension.class) // JUnit 5 +@InjectWith(MyLanguageWithDependenciesInjectorProvider.class) +public class YourTest { ... } ``` @@ -835,13 +844,13 @@ You should not put injector creation for referenced languages in your standalone You may also need to initialize imported ecore models that are not generated by your Xtext language. This should be done by using an explicit *MyModelPackage.eINSTANCE.getName();* in the *doSetup()* method of your respective language's StandaloneSetup class. Note that it is strongly recommended to follow this pattern instead of just using *@Before* methods in your \*Test class, as due to internal technical reasons that won't work anymore as soon as you have more than just one *@Test*. -```xtend -class MyLanguageStandaloneSetup extends MyLanguageStandaloneSetupGenerated { +```java +public class MyLanguageStandaloneSetup extends MyLanguageStandaloneSetupGenerated { - def static void doSetup() { + public static void doSetup() { if (!EPackage.Registry.INSTANCE.containsKey(MyPackage.eNS_URI)) EPackage.Registry.INSTANCE.put(MyPackage.eNS_URI, MyPackage.eINSTANCE); - new MyLanguageStandaloneSetup().createInjectorAndDoEMFRegistration + new MyLanguageStandaloneSetup().createInjectorAndDoEMFRegistration(); } } diff --git a/xtext-website/documentation/310_eclipse_support.md b/xtext-website/documentation/310_eclipse_support.md index 8d332a8864d..df0335a78a8 100644 --- a/xtext-website/documentation/310_eclipse_support.md +++ b/xtext-website/documentation/310_eclipse_support.md @@ -117,21 +117,22 @@ It is important to know that, for a given offset in a model file, many possible To provide a dummy proposal for the code of an `event` instance, you may introduce a specialization of the generated method and implement it as follows. This will propose `ZonkID` for an event with the name `Zonk`. -```xtend -override void completeEvent_Code( +```java +@Override +public void completeEvent_Code( Event event, Assignment assignment, ContentAssistContext context, ICompletionProposalAcceptor acceptor) { // call implementation of superclass - super.completeEvent_Code(model, assignment, context, acceptor) + super.completeEvent_Code(model, assignment, context, acceptor); // compute the plain proposal - val String proposal = event.getName() + "ID" + String proposal = event.getName() + "ID"; // Create and register the completion proposal: // The proposal may be null as the createCompletionProposal(..) // methods check for valid prefixes and terminal token conflicts. // The acceptor handles null-values gracefully. - acceptor.accept(createCompletionProposal(proposal, context)) + acceptor.accept(createCompletionProposal(proposal, context)); } ``` diff --git a/xtext-website/documentation/350_continuous_integration.md b/xtext-website/documentation/350_continuous_integration.md index 6ada5d1fa4b..9edeee2369b 100644 --- a/xtext-website/documentation/350_continuous_integration.md +++ b/xtext-website/documentation/350_continuous_integration.md @@ -116,7 +116,7 @@ The `pom.xml` for the language project contains information about how Maven shou org.eclipse.emf org.eclipse.emf.mwe2.launch - 2.11.0 + 2.11.1 org.eclipse.xtext @@ -247,6 +247,7 @@ To further speed up the p2 dependency resolution step, use the concrete build re | Xtext | EMF | MWE2/MWE | Xpand | Eclipse | All included in | | ------------- | ------------- | ----------- | ----------- | ----------- | ----------- | +| [2.20.0]({{page.upsite.xtext}}releases/2.20.0/) | [2.17.0]({{page.upsite.eclipse}}modeling/emf/emf/builds/release/2.17) (2.12.0) | [2.11.1]({{page.upsite.mwe}}releases/2.11.1/) (2.9.1) | [2.2.0]({{page.upsite.xpand}}releases/R201605260315) (1.4) | [4.14.0]({{page.upsite.eclipse}}releases/2019-12) (4.7.3) | [2019-12]({{page.upsite.eclipse}}releases/2019-12)| | [2.19.0]({{page.upsite.xtext}}releases/2.19.0/) | [2.17.0]({{page.upsite.eclipse}}modeling/emf/emf/builds/release/2.17) (2.12.0) | [2.11.0]({{page.upsite.mwe}}releases/2.11.0/) (2.9.1) | [2.2.0]({{page.upsite.xpand}}releases/R201605260315) (1.4) | [4.13.0]({{page.upsite.eclipse}}releases/2019-09) (4.7.3) | [2019-09]({{page.upsite.eclipse}}releases/2019-09)| | [2.18.0]({{page.upsite.xtext}}releases/2.18.0/) | [2.17.0]({{page.upsite.eclipse}}modeling/emf/emf/builds/release/2.17) (2.12.0) | [2.10.0]({{page.upsite.mwe}}releases/2.10.0/) (2.9.1) | [2.2.0]({{page.upsite.xpand}}releases/R201605260315) (1.4) | [4.12.0]({{page.upsite.eclipse}}releases/2019-06) (4.7.3) | [2019-06]({{page.upsite.eclipse}}releases/2019-06)| | [2.17.0]({{page.upsite.xtext}}releases/2.17.0/) | [2.17.0]({{page.upsite.eclipse}}modeling/emf/emf/builds/release/2.17) (2.12.0) | [2.10.0]({{page.upsite.mwe}}releases/2.10.0/) (2.9.1) | [2.2.0]({{page.upsite.xpand}}releases/R201605260315) (1.4) | [4.11.0]({{page.upsite.eclipse}}releases/2019-03) (4.7.3) | [2019-03]({{page.upsite.eclipse}}releases/2019-03)| @@ -262,7 +263,7 @@ To further speed up the p2 dependency resolution step, use the concrete build re | [2.8.3]({{page.upsite.xtext}}releases/2.8.3/), [2.8.2]({{page.upsite.xtext}}releases/2.8.2/), [2.8.1]({{page.upsite.xtext}}releases/2.8.1/) | [2.11.0]({{page.upsite.emf}}2.11/core/R201506010402/) (2.10.2) | [2.8.0]({{page.upsite.mwe}}releases/2.8.0/) (2.7.1) | [2.1.0]({{page.upsite.xpand}}releases/R201505260349) (1.4) | [4.5.0]({{page.upsite.eclipse}}eclipse/updates/4.5/R-4.5-201506032000/) (3.6) | [Mars R]({{page.upsite.eclipse}}releases/mars/201506241002/)| | [2.7.3]({{page.upsite.xtext}}releases/maintenance/R201411190455/) | [2.10.2]({{page.upsite.emf}}2.10.x/core/S201501230452/) (2.10) | [2.7.0]({{page.upsite.mwe}}releases/R201409021051/mwe2lang/) [1.3.4]({{page.upsite.mwe}}releases/R201409021027/mwe) (2.7.0/1.2) | [2.0.0]({{page.upsite.xpand}}releases/R201406030414) (1.4) | [4.4.2]({{page.upsite.eclipse}}eclipse/updates/4.4/R-4.4.2-201502041700) (3.6) |[Luna SR2]({{page.upsite.eclipse}}releases/luna/201502271000/)| -The following is an example target platform definition for Xtext 2.19.0 and Eclipse 4.13 alias 2019-09. +The following is an example target platform definition for Xtext 2.20.0 and Eclipse 4.14 alias 2019-12. ```xml @@ -271,7 +272,7 @@ The following is an example target platform definition for Xtext 2.19.0 and Ecli - + @@ -283,7 +284,7 @@ The following is an example target platform definition for Xtext 2.19.0 and Ecli - +