The Eclipse Modeling infrastructure and tools have evolved to be a de-facto standard in the context of modeling in general: lots of important and interesting systems have been built with Eclipse technologies such as EMF, Xtext, and GEF.
In this talk I give an introduction to a new Project at Eclipse (1): Xpect, a framework that allows to embed test expectations into comments inside your Xtext language. The approach is non-intrusive to your code, integrates with JUnit and has a smart editor for the Xpect-specific syntax.
Since Xpect separates DSL-Documents from Java-Test implementations, it becomes incredibly easy to add real-world code snippets to your test suite. You even can use your languages’s Xtext-Editor to edit your test cases.
We at Fiducia & GAD IT AG have been using Code Generation as a tool to develop our Banking Software "agree BAP" for about 15 years. As the codebase grew up to about 80 Mio. LOC the modeling tools that were used changed over time: from proprietary XML-based formats to UML models with MID Innovator and IBM RSA. On top of that, in-house developed Xtext DSLs are used for several purposes.
While creating languages and IDEs with Xtext is a breeze, it may become a little bumpy when you want to provide headless tools. Even though there exists decent support to generate and compile Java code from DSLs with Gradle or Maven, build systems for other target languages are still uncharted waters. Navigating through them depends a lot on your own technological decisions and of course on the target language of your choice.
One of the central aspects in Eclipse 4 is Dependency Injection, and for many cases it works like a charm. This talk is motivated by two cases in which the magic fades a bit, because some effort is required to make it work:
1. Injecting legacy components which are not instantiated by the application model
This is an issue if you are not developing E4 RCP applications, but want to enhance the Eclipse IDE using E4 technologies.
2. Performing Dual Injection with E4DI and Guice
Embedding support for expressions into Xtext based languages has become easy when Xbase is chosen as base language. However, deriving a language from Xbase implies the usage of a Java based type system with dependencies on JDT. For language implementations that need to be independent from Java or that should have a different type system it is required to embed an own expression language.
A model can be represented graphically and textually. While text is able to carry more detailed information, a diagram highlights the relationship between elements much better. In the end, a good tool should combine both, and use each notation where it suits best.