Eclipse IDE for Java

Dass Xtext 2.14 in der Lage ist, einen New Project Wizard zu generieren, wurde bereits im Blog berichtet. Aber auch ein vergleichbarer, ebenfalls auf Templates basierender Wizard, um DSL-Dateien in bestehenden Projekten zu erzeugen, ist nun neu dazu ... [More] gekommen. Dieser Wizard wird mit Eclipse Photon im Juni 2018 erscheinen – hier aber schon mal eine kurze Vorschau. Erzeugen des New File Wizards Der Wizard für neue Dateien wird nahezu genauso erzeugt wie der Wizard für neue Projekte. In der mwe2-Datei, die definiert, was generiert wird, muss folgender Abschnitt eingefügt werden: language = StandardLanguage {    name = "org.xtext.example.mydsl.MyDsl"    fileExtensions = "mydsl"    serializer = {        generateStub = false    }    fileWizard = {        generate = true    }} Die Generierung mittels Run As -> MWE2 Workflow generiert nun den Wizard und ein beispielhaftes Template. Im UI-Projekt der Sprache wird ein Package wizard generiert, das vor allem eine Datei MyDslFileTemplateProvider.xtend enthält (wobei der Name der Datei von dem Namen der Sprache abhängt). In dieser Datei wird der Inhalt des Wizards definiert. Weitere Konfigurationen sind normalerweise nicht nötig. Wenn lediglich ein einzelnes Template für eine Sprache generiert wird, dann hat der Wizard nur eine Seite. Auf ihr werden neben dem Verzeichnis und einem Namen alle Parameter des Templates angegeben. Gibt es mehrere Templates, wird auf der ersten Seite eine Combo-Box zur Auswahl des Templates angezeigt. Die Parameter werden dann auf der optionalen, zweiten Seite konfiguriert. Definieren eigener Templates Um das “Hello World” an die eigene Sprache anzupassen oder weitere Templates hinzuzufügen, muss der TemplateProvider – eine Klasse, die IFileTemplateProvider implementiert – angepasst werden. Dieser liefert mit der Methode getFileTemplates eine Liste mit allen verfügbaren Templates für die Sprache zurück. Standardmäßig sieht die Implementierung wie folgt aus: class MyDslFileTemplateProvider implements IFileTemplateProvider {    override getFileTemplates() {        #[new HelloWorldFile]    }} Das Hinzufügen eines weiteren Templates ist also das Hinzufügen einer neuen Instanz zu dieser Liste – zum Beispiel: Das neue Template muss eine Subklasse von AbstractFileTemplate sein. Am einfachsten lässt sich eine solche durch die Nutzung der Active Annotation FileTemplate erzeugen. Diese Annotation bietet die Möglichkeit, den Namen, ein Icon sowie einen Beschreibungstext für das Template festzulegen. Diese regeln die Darstellung des Templates in der Liste der verfügbaren Templates im Wizard. Man würde also in etwa so beginnen: @FileTemplate(label="Test", icon="file_template.png",    description="This creates a new hello world file.")final class HelloWorldFile {} Hier ist zumindest die Methode generateFile(IFileGenerator) zu implementieren. Der übergebene IFileGenerator enthält dabei eine einzelne Methode generate(CharSequence, CharSequence), die man nun beliebig oft aufrufen kann, um beim Beenden des Wizards Dateien anzulegen. Ein Aufruf, um ein einfaches “Hello World” zu erzeugen, kann dann zum Beispiel so aussehen: override generateFiles(IFileGenerator generator) { generator.generate('''«folder»/«name».mydsl''', ''' Hello «helloName»!     ''')} Zusätzliche Aufrufe von generate erzeugt weitere Dateien. Die Parameter für die Templates werden mit derselben API definiert, wie die Project Templates. Das vollständige “Hello World” sieht dann so aus: class MyDslFileTemplateProvider implements IFileTemplateProvider { override getFileTemplates() { #[new HelloWorldFile] }}@FileTemplate(label="Hello World", icon="file_template.png", description="Create a hello world for MyDsl.")final class HelloWorldFile { val helloName = combo("Hello Name:", #["Xtext", "World", "Foo", "Bar"], "The name to say 'Hello' to") override generateFiles(IFileGenerator generator) { generator.generate('''«folder»/«name».mydsl''', ''' Hello «helloName»! ''') }} Auch das Beisteuern weiterer Templates funktioniert analog zu den Projekt Templates über einen Extension Point. In diesem Fall über "org.eclipse.xtext.ui.fileTemplate". Da Eclipse Photon noch in etwa zwei Monaten Entfernung liegt, kommt hier schon einmal der Link zur nächtlichen Update Site: http://download.eclipse.org/modeling/tmf/xtext/updates/composite/latest/ [Less]

Learn how to count the elements of a collection that match a Predicate using Eclipse Collections.How many helicopters are there?How do you count using Eclipse Collections?The method count takes a Predicate as a parameter and returns the number of the ... [More] elements in a collection that match.Counting with a PredicateThere is also a countWith method which takes a Predicate2 and a countBy method which takes a Function.Counting elements of a CollectionHere’s a simple enum we’ll use to identify different things in a Collection.public enum SkyEntity{ HELICOPTER(true), SKYSCRAPER(false), BIRD(true); SkyEntity(boolean flies) { this.flies = flies; } private boolean flies; public boolean canFly() { return this.flies; }}Now, let’s count some things. First, I will create a MutableBag of SkyEntity instances using addOccurrences to set the counts directly. Then I will convert the MutableBag to a MutableList. Then I will use count to count the number of HELICOPTER and countWith to count the number of SKYSCRAPER.@Testpublic void count(){ MutableBag bag = Bags.mutable.empty(); bag.addOccurrences(SkyEntity.HELICOPTER, 12); bag.addOccurrences(SkyEntity.SKYSCRAPER, 10); bag.addOccurrences(SkyEntity.BIRD, 100); MutableList list = bag.toList(); Assert.assertEquals( bag.occurrencesOf(SkyEntity.HELICOPTER), list.count(SkyEntity.HELICOPTER::equals)); Assert.assertEquals( bag.occurrencesOf(SkyEntity.SKYSCRAPER), list.countWith(Object::equals, SkyEntity.SKYSCRAPER)); Bag flies = list.countBy(SkyEntity::canFly); Assert.assertEquals( flies.occurrencesOf(Boolean.TRUE), list.count(SkyEntity::canFly));}Finally, I group and count the SkyEntity who can and can’t fly using countBy with a Function which returns a Boolean.Counting Primitive CollectionsEclipse Collections has a full complement of primitive collections. Each primitive collections supports a count API. Here are a couple examples of counting with primitive collections.@Testpublic void countPrimitive(){ IntList intList = IntInterval.oneTo(10); Assert.assertEquals(5, intList.count(IntPredicates.isEven())); Assert.assertEquals(5, intList.count(IntPredicates.isOdd())); Assert.assertEquals(3, intList.count(i -> i % 3 == 0)); CharAdapter chars = Strings.asChars( "the quick brown fox jumps over the lazy dog"); Assert.assertEquals(2, chars.count(c -> c == 't')); Assert.assertEquals(8, chars.count(Character::isWhitespace));}APIs covered in the examples count / countWith — counts the number of elements of a collection that match a given Predicate or Predicate2. countBy — counts elements of a collection grouping them by some Function. Bags.mutable.empty — creates an empty MutableBag. occurrencesOf — counts the number of occurrences of an item in a Bag. toList — converts a collection to a MutableList. IntInterval.oneTo — creates an IntInterval which is an ImmutableIntList from one to the specified number. IntPredicates.isEven / isOdd — creates an IntPredicate which tests if an int is even or odd. Strings.asChars — creates a CharAdapter wrapping the specified String. Check out this presentation to learn more about the origins, design and evolution of the Eclipse Collections API.Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub. [Less]

What a crazy week helping host our annual European community conference in Copenhagen… it’s been wild to see the community grow since the CNCF took over the stewardship of the conference (thank you Joseph Jacks, still remember those conversations we ... [More] had in the early days): Somehow the crowd at #KubeCon is simply stunning… pic.twitter.com/MMzXgfSARg — Dirk Hohndel (@_dirkhh) May 2, 2018 I was also just blown away by the amount of CNCF ecosystem related jobs out there: Want to work with Cloud Native tech? #jobsboard #KubeCon pic.twitter.com/6N0rUDmESU — Tracy Miranda (@tracymiranda) May 4, 2018 I have a few hours until I board my flight home so I figure I would share some of my take aways from the event in a series of tweets: CNCF project adoption and the growth of the End User Community The amount of end users I’ve bumped into at the conference was incredible, insurance companies, medical, automative, government, airlines, tax offices and more. In Dan Kohn’s keynote, he covered our official CNCF End User Community which was setup as a way to ensure End Users have a voice in CNCF governance: End user community growth in @CloudNativeFdn demonstrates this is more than a vendor party. #Kubecon pic.twitter.com/BJB2hujrcR — Gabe Monroy (@gabrtv) May 2, 2018 CNCF has one of the largest, if not largest end user community membership of any open source foundation. I’m proud of what we built and mark my words, there will be a day when the number of official CNCF End Users will outnumber our vendors. Also, I was stoked to announce our first Top End User Award to Bloomberg showcasing one of our official end users using cloud native technology an interesting way: Favorite part of the keynote – end user awards; @cra presenting it to the first such recipient – @TechAtBloomberg, congratulations! #KubeCon pic.twitter.com/DIa0eNaerT — Sriram Subramanian (@sriramhere) May 2, 2018 If you’re using CNCF projects an interesting ways, I implore you to join our official End User Community so you have an official voice and more importantly, learn from other end users deploying CNCF projects. May a thousand [kubernetes] operators bloom In my opinion, one of the big themes of the conference was the rise of kubernetes operators. In Brandon Philips keynote, Red Hat (CoreOS) open sourced the Operator Framework which makes it easier to write and build operators: .@RedHat’s Operator Framework can also be used to create an enterprise-wide service catalog of Kubernetes apps @BrandonPhilips #kubecon pic.twitter.com/l497I6K3VT — The New Stack @ #KubeCon (@thenewstack) May 3, 2018 At the conference itself, there were many projects and companies announcing operators for their project or product (see dotmesh, spark, NATS, vitess, etc), expect this trend to continue and explode over the next year, you can see the growing list of operators out there via awesome-operators repo. CNCF is the center of open source serverless collaboration The CNCF Serverless Working Group launched their first version of the CloudEvents project: If you are interested in #cloudevents, you can find the specifications here: https://t.co/pYWz2E28te When you look at repo stats and pending PRs, you'll likely find that I've been doing a lot of writing on the transport mappings and event formats; some notes about the design: — Clemens Vasters (@clemensv) May 4, 2018 There was an incredible demo by Austen Collins showcasing the project across several cloud providers: This Friday @ #CloudNativeCon and #KubeCon, I'm doing a talk on #serverless / #FaaS everywhere, announcing a common format for event data, and demoing an event-driven, serverless architecture comprised of 8 cloud/FaaS providers. It's going to be awesome. https://t.co/Hs92k9HtQb pic.twitter.com/AF9uITD0wg — Austen Collins (@austencollins) May 2, 2018 For an effort that started under a year ago, it’s nice to see Azure, Google, Oracle, IBM and other major cloud providers collaborate in the working group and support various open source serverless initiatives, I look forward to what they will do next: Announced today and demo'd at #kubecon, first-class support for #CloudEvents on @Azure Event Grid. Thanks to @CloudNativeFdn for the great partnership! Open CloudEvents are the glue of the serverless world!https://t.co/ariMe043n5 pic.twitter.com/FheC31kl8C — Corey Sanders (@CoreySandersWA) May 4, 2018 CNCF 2020: Expanding ecosystem + Kubernetes: just run my code Alexis Richardson gave a keynote outlining his thoughts on the future vision of CNCF which I found delightful for everyone who doesn’t attend every CNCF TOC meeting: "Kubernetes, just run my code" the goal of 2020 CNCF strategy @monadic #KubeCon pic.twitter.com/aj6RiBwOqJ — Schlomo Schapiro (@schlomoschapiro) May 2, 2018 It’s not a surprise that I concur with a lot of these thoughts. In the bootstrapping days of CNCF, we were laying the foundation of projects required to bootstrap the ecosystem around Kubernetes and cloud native. The next step was increasing the reach of Kubernetes outside of just orchestration and focusing on technology areas as storage and security. The future of CNCF is all about increasing the mean time to developer satisfaction by improving the state of developer tooling. We need to get to the same point that developers are with Linux with Kubernetes, while super important foundational technology, developers don’t have to know the intimate details of how these systems work and instead stand on the shoulders of them to build their applications. Another additional thing I’d like to mention that Alexis didn’t bring up formally.  One of my goals in CNCF is to ensure we build a sustainable ecosystem of projects, members and end users. As our ecosystem matures and some of our projects proverbially cross the chasm (we use the graduate parlance in CNCF)… Kubernetes has graduated out of @CloudNativeFdn incubation. What does that mean? Kubernetes has crossed the chasm.#Kubecon pic.twitter.com/R7B0zgfkDE — Gabe Monroy (@gabrtv) May 2, 2018 How do we ensure each of these parties are receiving value from their participation in the foundation? It’s something I think about on a daily basis as more CNCF projects get embedded everywhere, graduate and cross the chasm. Kubernetes maturing and container standardization unlocks innovation At the conference, Google open sourced gVisor as another approach to container runtimes which in my biased opinion is made possible due to OCI standardization efforts to allow this type of innovation without fear of breaking compatibility. As part of gVisor, runsc(like runc in OCI) provides an isolation boundary between the application and the host kernel and they have a ton of information in their README about the tradeoffs versus other container runtimes out there: With more runtimes like gVisor coming out I'm trying to find a good way to abstract the runc CLI so that it's easier for people to build their own when they implement @OCI_ORG specs. This is that I have so far:https://t.co/URQdGqzBA8 — Michael Crosby (@crosbymichael) May 2, 2018 Conclusion There are a lot more things to mention (e.g., rise of enovy and it becoming embedded everywhere, cloud native programming languages, chaos engineering) but I have to now board a flight home and get some sleep. Personally, I’m nothing but humbled by the growth of the community and conference the last few years, it’s been an honor helping build it out since the beginning. If you have any suggestions on improving the event or our community in anyway, please reach out via Twitter or shoot me an email: completely humbled with how much the @CloudNativeFdn has grown, hope you enjoyed #kubecon #cloudnativecon and please feel free to personally send me feedback on how we can make things better for you in the future — Chris Aniszczyk (@cra) May 4, 2018 We do listen to feedback and as an example, in Austin, people complained that the videos were taking too long to post and we aimed to have a quicker turn around this time and followed through with that in Copenhagen: missed #kubecon #cloudnativecon in Copenhagen? don't worry, videos are being uploaded to the @CloudNativeFdn as we speak! https://t.co/0M2lZL6z55 pic.twitter.com/HFpuQhzPy2 — Chris Aniszczyk (@cra) May 5, 2018 Thank you again for attending and see you in Shanghai and Seattle! [Less]

What a crazy week helping host our annual European community conference in Copenhagen… it’s been wild to see the community grow since the CNCF took over the stewardship of the conference (thank you Joseph Jacks, still remember those conversations we ... [More] had in the early days): Somehow the crowd at #KubeCon is simply stunning… pic.twitter.com/MMzXgfSARg — Dirk Hohndel (@_dirkhh) May 2, 2018 I was also just blown away by the amount of CNCF ecosystem related jobs out there: Want to work with Cloud Native tech? #jobsboard #KubeCon pic.twitter.com/6N0rUDmESU — Tracy Miranda (@tracymiranda) May 4, 2018 I have a few hours until I board my flight home so I figure I would share some of my take aways from the event in a series of tweets: CNCF project adoption and the growth of the End User Community The amount of end users I’ve bumped into at the conference was incredible, insurance companies, medical, automative, government, airlines, tax offices and more. In Dan Kohn’s keynote, he covered our official CNCF End User Community which was setup as a way to ensure End Users have a voice in CNCF governance: End user community growth in @CloudNativeFdn demonstrates this is more than a vendor party. #Kubecon pic.twitter.com/BJB2hujrcR — Gabe Monroy (@gabrtv) May 2, 2018 CNCF has one of the largest, if not largest end user community membership of any open source foundation. I’m proud of what we built and mark my words, there will be a day when the number of official CNCF End Users will outnumber our vendors. Also, I was stoked to announce our first Top End User Award to Bloomberg showcasing one of our official end users using cloud native technology an interesting way: Favorite part of the keynote – end user awards; @cra presenting it to the first such recipient – @TechAtBloomberg, congratulations! #KubeCon pic.twitter.com/DIa0eNaerT — Sriram Subramanian (@sriramhere) May 2, 2018 If you’re using CNCF projects an interesting ways, I implore you to join our official End User Community so you have an official voice and more importantly, learn from other end users deploying CNCF projects. May a thousand [kubernetes] operators bloom In my opinion, one of the big themes of the conference was the rise of kubernetes operators. In Brandon Philips keynote, Red Hat (CoreOS) open sourced the Operator Framework which makes it easier to write and build operators: .@RedHat’s Operator Framework can also be used to create an enterprise-wide service catalog of Kubernetes apps @BrandonPhilips #kubecon pic.twitter.com/l497I6K3VT — The New Stack @ #KubeCon (@thenewstack) May 3, 2018 At the conference itself, there were many projects and companies announcing operators for their project or product (see dotmesh, spark, NATS, vitess, etc), expect this trend to continue and explode over the next year, you can see the growing list of operators out there via awesome-operators repo. CNCF is the center of open source serverless collaboration The CNCF Serverless Working Group launched their first version of the CloudEvents project: https://twitter.com/clemensv/status/992478395178119168 There was an incredible demo by Austen Collins showcasing the project across several cloud providers: This Friday @ #CloudNativeCon and #KubeCon, I'm doing a talk on #serverless / #FaaS everywhere, announcing a common format for event data, and demoing an event-driven, serverless architecture comprised of 8 cloud/FaaS providers. It's going to be awesome. https://t.co/Hs92k9HtQb pic.twitter.com/AF9uITD0wg — Austen Collins (@austencollins) May 2, 2018 For an effort that started under a year ago, it’s nice to see Azure, Google, Oracle, IBM and other major cloud providers collaborate in the working group and support various open source serverless initiatives, I look forward to what they will do next: Announced today and demo'd at #kubecon, first-class support for #CloudEvents on @Azure Event Grid. Thanks to @CloudNativeFdn for the great partnership! Open CloudEvents are the glue of the serverless world!https://t.co/ariMe043n5 pic.twitter.com/FheC31kl8C — Corey Sanders (@CoreySandersWA) May 4, 2018 CNCF 2020: Expanding ecosystem + Kubernetes: just run my code Alexis Richardson gave a keynote outlining his thoughts on the future vision of CNCF which I found delightful for everyone who doesn’t attend every CNCF TOC meeting: "Kubernetes, just run my code" the goal of 2020 CNCF strategy @monadic #KubeCon pic.twitter.com/aj6RiBwOqJ — Schlomo Schapiro (@schlomoschapiro) May 2, 2018 It’s not a surprise that I concur with a lot of these thoughts. In the bootstrapping days of CNCF, we were laying the foundation of projects required to bootstrap the ecosystem around Kubernetes and cloud native. The next step was increasing the reach of Kubernetes outside of just orchestration and focusing on technology areas as storage and security. The future of CNCF is all about increasing the mean time to developer satisfaction by improving the state of developer tooling. We need to get to the same point that developers are with Linux with Kubernetes, while super important foundational technology, developers don’t have to know the intimate details of how these systems work and instead stand on the shoulders of them to build their applications. Another additional thing I’d like to mention that Alexis didn’t bring up formally.  One of my goals in CNCF is to ensure we build a sustainable ecosystem of projects, members and end users. As our ecosystem matures and some of our projects proverbially cross the chasm (we use the graduate parlance in CNCF)… Kubernetes has graduated out of @CloudNativeFdn incubation. What does that mean? Kubernetes has crossed the chasm.#Kubecon pic.twitter.com/R7B0zgfkDE — Gabe Monroy (@gabrtv) May 2, 2018 How do we ensure each of these parties are receiving value from their participation in the foundation? It’s something I think about on a daily basis as more CNCF projects get embedded everywhere, graduate and cross the chasm. Kubernetes maturing and container standardization unlocks innovation At the conference, Google open sourced gVisor as another approach to container runtimes which in my biased opinion is made possible due to OCI standardization efforts to allow this type of innovation without fear of breaking compatibility. As part of gVisor, runsc(like runc in OCI) provides an isolation boundary between the application and the host kernel and they have a ton of information in their README about the tradeoffs versus other container runtimes out there: With more runtimes like gVisor coming out I'm trying to find a good way to abstract the runc CLI so that it's easier for people to build their own when they implement @OCI_ORG specs. This is that I have so far:https://t.co/URQdGqzBA8 — Michael Crosby (@crosbymichael) May 2, 2018 Conclusion There are a lot more things to mention (e.g., rise of enovy and it becoming embedded everywhere, cloud native programming languages, chaos engineering) but I have to now board a flight home and get some sleep. Personally, I’m nothing but humbled by the growth of the community and conference the last few years, it’s been an honor helping build it out since the beginning. If you have any suggestions on improving the event or our community in anyway, please reach out via Twitter or shoot me an email: completely humbled with how much the @CloudNativeFdn has grown, hope you enjoyed #kubecon #cloudnativecon and please feel free to personally send me feedback on how we can make things better for you in the future — Chris Aniszczyk (@cra) May 4, 2018 We do listen to feedback and as an example, in Austin, people complained that the videos were taking too long to post and we aimed to have a quicker turn around this time and followed through with that in Copenhagen: missed #kubecon #cloudnativecon in Copenhagen? don't worry, videos are being uploaded to the @CloudNativeFdn as we speak! https://t.co/0M2lZL6z55 pic.twitter.com/HFpuQhzPy2 — Chris Aniszczyk (@cra) May 5, 2018 Thank you again for attending and see you in Shanghai and Seattle! [Less]

Meet the communities, learn about the technologies and get the latest news around these important Java initiatives. Newcomers to these projects can experience talks ranging from Building a 12-factor microservice in half an hour to an introduction to ... [More] JarkartaEE,  Java EE to Jakarta EE: a user perspective. Those already involved can hear the latest New & Noteworthy on the Eclipse Microprofile project or learn about JAX-RS 2.1 & Beyond. There’s much more - follow this link to these topics and start planning your conference! [Less]

"EclipseCon France is around the corner, and we at TypeFox are proud to sponsor this great community gathering again. Eclipse has morphed from being an IDE, over a tooling platform to an entire ecosystem, adopting trends and leading new endeavors like IoT, cloud technology and Jakarta EE ..."

This month, read all about Eclipse projects: Collections, JNoSQL, MicroProfile, OpenJ9, and Vert.x

Unit tests written for Xtext DSLs are typically using Xtext’s testing infrastructure provided by the org.eclipse.xtext.testing bundle. Older tests might even still use the deprecated org.eclipse.xtext.junit4 bundle. Tests for DSLs need to inject a ... [More] language specific IInjectorProvider with an @InjectWith annotation. Additionally a specialized JUnit runner, the XtextRunner, is used with the @RunWith annotation to run the test.  An Xtext test therefore looks like this: @RunWith(XtextRunner)@InjectWith(MyDslInjectorProvider) class MyDslSomethingTest { ... } The XtextRunner uses the injector provider, does the member injection into the class-under-test and takes care that internal registries are reset after test execution. This is required to avoid side effects from modifications on global EMF registries during test execution. However, JUnit runners are specific to JUnit 4 and therefore XtextRunner can only be used to run tests with JUnit 4.  To support the new JUnit 5 framework Xtext needed something equivalent to what the XtextRunner does. In JUnit 5, additional logic that needs to be executed in a test’s lifecycle can be added with means of Extensions. JUnit 5 Extensions are more powerful than Runners. Especially there can be multiple of them, while you can only have a single runner. The replacement for XtextRunner is the new class org.eclipse.xtext.testing.extensions.InjectionExtension. Use it together with the @ExtendWith annotation. So a typical test now looks as follows: @ExtendWith(InjectionExtension) @InjectWith(MyDslInjectorProvider) class MyDslSomethingTest { ... } That’s basically it to make tests run with JUnit 5! Easy, isn’t it? In Eclipse, you can run them as you are used to with the Run As / JUnit Test action. Note that the test execution now shows that it was run with the JUnit 5 engine. JUnit 5 dependencies Of course a testing project needs different dependencies with JUnit 5. The following dependencies are used in the test project’s MANIFEST.MF: org.junit.jupiter.api;bundle-version="5.1.0", org.junit.jupiter.engine;bundle-version="5.1.0", org.junit.platform.commons;bundle-version="1.1.0", org.junit.platform.engine;bundle-version="1.1.0", org.opentest4j;bundle-version="1.0.0", When using Gradle add these dependencies to the build.gradle file in the test project: dependencies {     compile project(':org.xtext.example.mydsl')     testCompile "org.junit.jupiter:junit-jupiter-api:5.1.0"     testCompile "org.junit.jupiter:junit-jupiter-engine:5.1.0"     testCompile "org.junit.platform:junit-platform-commons:1.1.0"     testCompile "org.junit.platform:junit-platform-engine:1.1.0"     testCompile "org.opentest4j:opentest4j:1.0.0"     testCompile "org.eclipse.xtext:org.eclipse.xtext.testing:${xtextVersion}"     testCompile "org.eclipse.xtext:org.eclipse.xtext.xbase.testing:${xtextVersion}" } If you are creating Eclipse plugins, JUnit 5.1 must be part of your target platform. That version has just recently been added to Eclipse Orbit and there is at the time of writing of this article just an integration build repository available hosting these bundles: http://download.eclipse.org/tools/orbit/downloads/drops/I20180417184143/repositoryIn the near future, use a more stable repository. That will be the recommended repository for Eclipse Photon, or before the Photon release, the repository for the Photon M7 milestone. New Project Wizard Xtext’s New Project Wizard now lets you decide which JUnit version you want to use for new projects. In the language’s .mwe2 workflow file the junitSupport will configured for version 5 then, which instructs Xtext’s generator to add the required dependencies to the test project and create the example parser test in JUnit 5 style. Migrating Tests To migrate your Xtext tests to JUnit 5 the most important things have already mentioned above: Make sure you add the JUnit 5 dependencies to your tests project
  Replace @RunWith(XtextRunner.class) by @ExtendWith(InjectionExtensions.class)
  Replace import org.junit.Test by org.junit.jupiter.api.Test
  Replace import org.junit.Assert by org.junit.jupiter.api.Assertions
 Conclusion With Xtext 2.14 tests can be written and executed with JUnit 5. For new projects Xtext’s wizard produces the right configuration automatically. However, migration of existing Xtext test projects and classes is quite easy.  [Less]

Unit tests written for Xtext DSLs are typically using Xtext’s testing infrastructure provided by the org.eclipse.xtext.testing bundle. Older tests might even still use the deprecated org.eclipse.xtext.junit4 bundle. Tests for DSLs need to inject a ... [More] language specific IInjectorProvider with an @InjectWith annotation. Additionally a specialized JUnit runner, the XtextRunner, is used with the @RunWith annotation to run the test.  An Xtext test therefore looks like this: @RunWith(XtextRunner)@InjectWith(MyDslInjectorProvider) class MyDslSomethingTest { ... } The XtextRunner uses the injector provider, does the member injection into the class-under-test and takes care that internal registries are reset after test execution. This is required to avoid side effects from modifications on global EMF registries during test execution. However, JUnit runners are specific to JUnit 4 and therefore XtextRunner can only be used to run tests with JUnit 4.  To support the new JUnit 5 framework Xtext needed something equivalent to what the XtextRunner does. In JUnit 5, additional logic that needs to be executed in a test’s lifecycle can be added with means of Extensions. JUnit 5 Extensions are more powerful than Runners. Especially there can be multiple of them, while you can only have a single runner. The replacement for XtextRunner is the new class org.eclipse.xtext.testing.extensions.InjectionExtension. Use it together with the @ExtendWith annotation. So a typical test now looks as follows: @ExtendWith(InjectionExtension) @InjectWith(MyDslInjectorProvider) class MyDslSomethingTest { ... } That’s basically it to make tests run with JUnit 5! Easy, isn’t it? In Eclipse, you can run them as you are used to with the Run As / JUnit Test action. Note that the test execution now shows that it was run with the JUnit 5 engine. JUnit 5 dependencies Of course a testing project needs different dependencies with JUnit 5. The following dependencies are used in the test project’s MANIFEST.MF: org.junit.jupiter.api;bundle-version="5.1.0", org.junit.jupiter.engine;bundle-version="5.1.0", org.junit.platform.commons;bundle-version="1.1.0", org.junit.platform.engine;bundle-version="1.1.0", org.opentest4j;bundle-version="1.0.0", When using Gradle add these dependencies to the build.gradle file in the test project: dependencies {     compile project(':org.xtext.example.mydsl')     testCompile "org.junit.jupiter:junit-jupiter-api:5.1.0"     testCompile "org.junit.jupiter:junit-jupiter-engine:5.1.0"     testCompile "org.junit.platform:junit-platform-commons:1.1.0"     testCompile "org.junit.platform:junit-platform-engine:1.1.0"     testCompile "org.opentest4j:opentest4j:1.0.0"     testCompile "org.eclipse.xtext:org.eclipse.xtext.testing:${xtextVersion}"     testCompile "org.eclipse.xtext:org.eclipse.xtext.xbase.testing:${xtextVersion}" } If you are creating Eclipse plugins, JUnit 5.1 must be part of your target platform. That version has just recently been added to Eclipse Orbit and there is at the time of writing of this article just an integration build repository available hosting these bundles: http://download.eclipse.org/tools/orbit/downloads/drops/I20180417184143/repositoryIn the near future, use a more stable repository. That will be the recommended repository for Eclipse Photon, or before the Photon release, the repository for the Photon M7 milestone. New Project Wizard Xtext’s New Project Wizard now lets you decide which JUnit version you want to use for new projects. In the language’s .mwe2 workflow file the junitSupport will configured for version 5 then, which instructs Xtext’s generator to add the required dependencies to the test project and create the example parser test in JUnit 5 style. Migrating Tests To migrate your Xtext tests to JUnit 5 the most important things have already mentioned above: Make sure you add the JUnit 5 dependencies to your tests project
  Replace @RunWith(XtextRunner.class) by @ExtendWith(InjectionExtensions.class)
  Replace import org.junit.Test by org.junit.jupiter.api.Test
  Replace import org.junit.Assert by org.junit.jupiter.api.Assertions
 Conclusion With Xtext 2.14 tests can be written and executed with JUnit 5. For new projects Xtext’s wizard produces the right configuration automatically. However, migration of existing Xtext test projects and classes is quite easy.  [Less]

Unit tests written for Xtext DSLs are typically using Xtext’s testing infrastructure provided by the org.eclipse.xtext.testing bundle. Older tests might even still use the deprecated org.eclipse.xtext.junit4 bundle. Tests for DSLs need to inject a ... [More] language specific IInjectorProvider with an @InjectWith annotation. Additionally a specialized JUnit runner, the XtextRunner, is used with the @RunWith annotation to run the test.  An Xtext test therefore looks like this: @RunWith(XtextRunner)@InjectWith(MyDslInjectorProvider) class MyDslSomethingTest { ... } The XtextRunner uses the injector provider, does the member injection into the class-under-test and takes care that internal registries are reset after test execution. This is required to avoid side effects from modifications on global EMF registries during test execution. However, JUnit runners are specific to JUnit 4 and therefore XtextRunner can only be used to run tests with JUnit 4.  To support the new JUnit 5 framework Xtext needed something equivalent to what the XtextRunner does. In JUnit 5, additional logic that needs to be executed in a test’s lifecycle can be added with means of Extensions. JUnit 5 Extensions are more powerful than Runners. Especially there can be multiple of them, while you can only have a single runner. The replacement for XtextRunner is the new class org.eclipse.xtext.testing.extensions.InjectionExtension. Use it together with the @ExtendWith annotation. So a typical test now looks as follows: @ExtendWith(InjectionExtension) @InjectWith(MyDslInjectorProvider) class MyDslSomethingTest { ... } That’s basically it to make tests run with JUnit 5! Easy, isn’t it? In Eclipse, you can run them as you are used to with the Run As / JUnit Test action. Note that the test execution now shows that it was run with the JUnit 5 engine. JUnit 5 dependencies Of course a testing project needs different dependencies with JUnit 5. The following dependencies are used in the test project’s MANIFEST.MF: org.junit.jupiter.api;bundle-version="5.1.0", org.junit.jupiter.engine;bundle-version="5.1.0", org.junit.platform.commons;bundle-version="1.1.0", org.junit.platform.engine;bundle-version="1.1.0", org.opentest4j;bundle-version="1.0.0", When using Gradle add these dependencies to the build.gradle file in the test project: dependencies {     compile project(':org.xtext.example.mydsl')     testCompile "org.junit.jupiter:junit-jupiter-api:5.1.0"     testCompile "org.junit.jupiter:junit-jupiter-engine:5.1.0"     testCompile "org.junit.platform:junit-platform-commons:1.1.0"     testCompile "org.junit.platform:junit-platform-engine:1.1.0"     testCompile "org.opentest4j:opentest4j:1.0.0"     testCompile "org.eclipse.xtext:org.eclipse.xtext.testing:${xtextVersion}"     testCompile "org.eclipse.xtext:org.eclipse.xtext.xbase.testing:${xtextVersion}" } If you are creating Eclipse plugins, JUnit 5.1 must be part of your target platform. That version has just recently been added to Eclipse Orbit and there is at the time of writing of this article just an integration build repository available hosting these bundles: http://download.eclipse.org/tools/orbit/downloads/drops/I20180417184143/repositoryIn the near future, use a more stable repository. That will be the recommended repository for Eclipse Photon, or before the Photon release, the repository for the Photon M7 milestone. New Project Wizard Xtext’s New Project Wizard now lets you decide which JUnit version you want to use for new projects. In the language’s .mwe2 workflow file the junitSupport will configured for version 5 then, which instructs Xtext’s generator to add the required dependencies to the test project and create the example parser test in JUnit 5 style. Migrating Tests To migrate your Xtext tests to JUnit 5 the most important things have already mentioned above: Make sure you add the JUnit 5 dependencies to your tests project
  Replace @RunWith(XtextRunner.class) by @ExtendWith(InjectionExtensions.class)
  Replace import org.junit.Test by org.junit.jupiter.api.Test
  Replace import org.junit.Assert by org.junit.jupiter.api.Assertions
 Conclusion With Xtext 2.14 tests can be written and executed with JUnit 5. For new projects Xtext’s wizard produces the right configuration automatically. However, migration of existing Xtext test projects and classes is quite easy.  [Less]