Xtext is the de facto standard framework for the development of sophisticated domain specific languages (DSLs) in the Eclipse ecosystem and beyond. Even though the framework already provides a buckload of important features, we won’t become tired rethinking the architecture at scale or smaller features in isolation. Since Xtext version 2.20 is in the works, it’s about time to unveil a few of the planned features and work items.
GRACES is a software-based assistive tool that makes Software and System Engineering diagrams and graphical models accessible to blind engineers and software professionals. In particular, the current version of the tool allows blind users to use a screen reader to inspect existent Unified Modeling Language (UML) class diagrams, created by other individuals with mainstream graphical modelling products; as well as to create their own models through a purely textual notation defined in the GRACES tool Domain-Specific Language (DSL), to be further imported by users of graphical modelling tools. The employment of this tool opens the access to highly qualified positions that make a heavy use of such modelling elements.
Domain specific language serve the needs of different domains and different technologies in the Software industries in various ways such as configuration, testing, automation, validation, work flow management and behavioral description. Since DSL is limited in scope and easy to learn, everyone can work on for his or her demands.
There are several use cases with respect to DSL. This session explains How can define/automate behaviour of exisiting applications (from its exposed web services) with DSL (with help of Xtext framework).
Demo use cases
Eclipse Xtext is a mature and powerful framework for building domain specific languages - standalone, backed by a language server (LSP) and with an Eclipse IDE. Despite the existing documentation, tutorials and tons of third party material, there are some problems and obstacles new Xtext users are stumbling over regularly and ask in the Xtext forums or on Stackoverflow. In this talk I will give an overview on some of the most common issues and show possible solutions.
Defining DSLs in the Eclipse universe has become almost a normal thing and there are incredible frameworks out there to do that. Some of them are textual, others are graphical and from time to time there comes a flood of different attempts to mix both notations. The story of mixed notations is old, yet still not solved in a common way that has proven to be “the solution”. Of course there are plenty of interesting technical challenges, but let’s step back and rethink who is our target audience to see if we are solving a real problem.
Code formatting is an opinionated beast. It always has been a matter of taste, and it always will be a matter of taste. This is the reason, why professional formatting tools, such as Eclipse JDT, offer a gazillion number of options. Which is still not sufficient enough. After all, you can override them inline with tag-comments to make the formatter shut up. Can't we do better than that? What if we could use machine learning techniques to detect the preferred code style that was used in a codebase so far? Turned out, we can.
With its history of 10 years passionate software engineering, dozens of contributors and millions of lines of source code, Xtext has become the de facto standard for the development of sophisticated domain specific languages in the Eclipse ecosystem and beyond. The release of Xtext 2.14 is still hot and yet Xtext 2.15 is already keeping us busy. Time to reflect on the recently introduced features and time to look forward and talk about the things to come.
Domain-specific languages (DSLs) are a powerful tool to capture arbitrary abstractions of an application domain and map it to code. Eclipse really shines when it comes to integrating DSLs in rich-client workbenches, but how about web-based IDEs?
In this talk you will learn how to bundle the power of four Eclipse frameworks to build a cloud-based IDE with support for your own DSLs: