Keywords play a central role in Xtext DSLs to define the languages general structure. In many cases a single keyword is sufficient to specify what is expected next. Although Xtext generally supports multiple consecutive keywords the default content assist implementation will propose one keyword after another instead of concatenating consecutive keywords. This can lead to confusing proposals for the user. This article will help you to prevent this confusion.

After demonstrating the problem with a simple DSL it will be shown that slighty changing the grammar generates the infrastructure to offer more valuable proposals. The source code for this example is available in our Github repository. Further examples for cases in which a single keyword is sufficient to specify what is expected next can be found in the blog articals regarding controlled natural languages described by Christoph Knauf.

Sample Grammar

As an example we will use the well-known domainmodel example DSL that is shipped with the Xtext SDK, extended by the new concept Relation. A Relation comes with its own semantics that is represented by a sequence of keywords. While depends on carries the semantics that one entity is relying on the existence of a certain other entity, is composed of defines a composition dependency between two entities. Since putting each keyword in its own quote is considered as good grammar style the keyword sequences are separated.

grammar org.eclipse.xtext.example.domainmodel.Domainmodel with org.eclipse.xtext.xbase.Xbase

generate domainmodel "http://www.xtext.org/example/Domainmodel"

DomainModel:
    importSection=XImportSection?
    elements+=Entity*;

Entity:
    'entity' name=ValidID ('extends' superType=JvmParameterizedTypeReference)? '{'
        properties+=Property*
        relations+=Relation*
    '}';

Relation:
    ('depends' 'on' | 'is' 'composed' 'of') referencedEntity=[Entity]
;

Property:
name=ValidID ':' type=JvmTypeReference;

As an example we want to define an entity Person and an entity Club where the entity Club is composed of Persons. Within the entity Club the proposal provider is invoked leading to the following suggestions:

The figure above shows the proposals based on the default implementation of the content assist that offers each first keyword of the Relation rule. As a consequence each single keyword of the sequence will be proposed by an additional hit of CTRL + Space. Especially the beginning of the second keyword sequence is gives no information about the whole keyword sequence making the proposal nearly unusable. To improve the suggestion of multiple consecutive keywords the grammar and the proposal provider will be slightly adjusted.

Grammar Adjustments

To enable the proposal provider to make more valuable suggestions the keyword sequences are moved to their own parser rule that is than referenced from the Relation rule.

Relation:
    (DependsOn | IsComposedOf) referencedEntity=[Entity]
;

DependsOn:
    'depends' 'on'
;

IsComposedOf:
    'is' 'composed' 'of'
;

Although, the change makes no difference to the grammar itself it causes valuable changes in the generated language framework and especially in the proposal provider. Each of the keyword sequences now has its own complete_ method in the AbstractDomainmodelProposalProvider.

    public void complete_DependsOn(EObject model, RuleCall ruleCall, ContentAssistContext context, ICompletionProposalAcceptor acceptor) {
        // subclasses may override
    }
    public void complete_IsComposedOf(EObject model, RuleCall ruleCall, ContentAssistContext context, ICompletionProposalAcceptor acceptor) {
        // subclasses may override
    }

As the by default generated methods suggest we now implement each of these in the DomainmodelProposalProvider to return the whole sequence of keywords as a proposal. First, as preparation we inject the DomainmodelGrammarAccess as an extension to the DomainmodelProposalProvider. The GrammarAccess is used in the overwritten complete_ methods to get easy access to the keyword sequence defined by the grammar.

class DomainmodelProposalProvider extends AbstractDomainmodelProposalProvider {

    @Inject extension DomainmodelGrammarAccess

Second, the complete_ methods are overwritten to create a proposal string that contains all elements of the keyword sequence. The injected DomainmodelGrammarAccess is used to get the group of keywords that is than passed to the createKeywordProposal method that does the real magic.

override complete_DependsOn(EObject model, RuleCall ruleCall, ContentAssistContext context, ICompletionProposalAcceptor acceptor) {
    dependsOnAccess.group.createKeywordProposal(context,acceptor)
}
override complete_IsComposedOf(EObject model, RuleCall ruleCall, ContentAssistContext context, ICompletionProposalAcceptor acceptor) {
    isComposedOfAccess.group.createKeywordProposal(context,acceptor)
}

The following code snippet shows how a coherent keyword sequence is computed and proposed. After checking that the passed in group is not null the proposal string is concatenated. First, the list of elements from the group are retrieved and filtered for instances of org.eclipse.xtext.Keyword. Second, the values of each Keyword are fetched and concatenated using the join method with a single space as delimiter. Finally, the proposalString is turned into a completion proposal that is than handed over to the ICompletionProposalAcceptor calling the accept method.

def createKeywordProposal(Group group, ContentAssistContext context, ICompletionProposalAcceptor acceptor) {
    if (group == null) {
        return null
    }
    val proposalString = group.elements.filter(Keyword).map[value].join(" ") + " "
    acceptor.accept(createCompletionProposal(proposalString, proposalString, null, context))
}

The following figure shows the newly created proposal strings that now contain the whole sequence of keywords.

Conclusion

As demonstrated above the default keyword support of the Xtext language workbench is sufficient for single keywords. However, there are situations in which multiple consecutive keywords are required to define thorough and comprehensive language statements. To cope with sequences of keywords as a whole small changes to the grammar are required. In addition to solely proposing consecutive keywords the overwritten methods can also be used to filter, e.g. allow only one depends on relation per entity. All in all, the rather small changes to the grammar make the suggested consecutive keywords more valuable and in addition create new opportunities to improve the overall proposals.

Have you heard about MARTE?

Well, MARTE is the OMG Modeling and Analysis of Real-Time Embedded Systems profile.

Yes, it’s a mouthful, but if you are interested in the nitty-gritty of embedded systems, it can be very useful!

Here’s a short message from one of my minion about it:

We are pleased to announce that the MARTE feature has been transformed into a Papyrus Component. The MARTE 1.2.1 release, for Eclipse Neon, can be downloaded from [1]. We advise you to uninstal4l any previous version of MARTE beforehand.

The old MARTE projects, in the extra folder of the main Papyrus repository, will soon be completely removed. The new repository can be cloned from [2].

[1] http://download.eclipse.org/modeling/mdt/papyrus/components/marte/neon/
[2] https://git.eclipse.org/r/papyrus/org.eclipse.papyrus-marte

Aren’t you lucky that I support it?

You might have missed it, but my Neon.1 version (a.k.a. 2.0.1) is available!

My minions did their usual excellent job in keeping me up to date!

Go get it…I’ll wait…

The source for the Eclipse Project Handbook is in AsciiDoc format (rendered using Asciidoctor via Maven), and includes embedded Graphviz graph descriptions (which are rendered into embedded images). Proofing those images is a bit of a pain: it requires that I actually build the handbook and use a browser to view the results.

A few years ago, I wrote an Image Util plug-in, primarily as an excuse to learn about how adapters work. I pulled that old plug-in into my current Eclipse IDE (Neon edition) and was quite happy to learn that it still works. The implementation is simple enough: it provides an Image Preview view that—when possible—adapts the current selection into an ImageProvider that (curiously enough) provides an image to display. It works brilliantly for file selections and I even made it work for selections in the Remote Systems Explorer.

So, frustrated with the round-trip process for testing images (after spending some quality time hunting down an existing solution), I created a plug-in that adapts an arbitrary text selection into an image provider that invokes the Graphviz dot command to render the selection into an image. I was a bit stunned when my first attempt at implementing it just worked. It works in every text editor that I’ve tested it with (including the handy AsciiDoc WikiText editor).

Anyway… it’s a quick and dirty hack (albeit, a hack with some potential) that requires the command-line tool be installed, but I think that it demonstrates some of the power that comes when your platform has well-documented and stable APIs (FWIW, the implementation has about seven meaningful lines of code).

Note that the implementation is currently only available as source code. Sorry, there’s no software site yet. Maybe that’s something we can work on at the EclipseCon Europe 2016 Hackathon!

I upgraded to Fedora 25 (beta), which by default uses the new Wayland display server, (which is a replacement for x11).

Most applications work OK. Even copy and paste now works.However some applications have trouble.

Eclipse has some troubles. My observations:

• Menu bar disappears when you drag the window around.
• Dialogues have a few button cut off, (apply, ok, cancle).
• There is a delay of a bout ~1 second when you click on something.
• Tabs get messed up if you click on one. (e.g they are split into left/right), it seems Dragging of parts is undesirably activated.

Overall, Eclipse isn’t quite usable on Wayland yet. However, efforts to improve Eclipse behavior on Wayland is under way:

Bug 496923 – [Wayland] Improve support for Wayland in 4.7
https://bugs.eclipse.org/bugs/show_bug.cgi?id=496923

In the mean time, while in Wayland, you can force Eclipse to use the x11 backend:

export GDK_BACKEND=x11
./eclipse

This can be used for other applications also. For example Autokey is buggy on wayland, I used that for that app as well.

Hang on tight and follow the bug above for updates.

For several automotive customers, we are building (Eclipse-based) systems that process engineering data – not only interactively, but in nightly jobs. From time to time, there might be a problem in test or even production systems, throwing an exception.

The default of Java is obviously only to show the stack trace. For a quick analysis, you might also want to like to know which arguments have been passed to the method that the exception was thrown in.

We are using AspectJ to “weave” relevant plugins (we use runtime weaving). The aspect looks like this:

@Aspect
public class ExceptionAspect {
     @AfterThrowing(pointcut = "execution(* my.package.to.be.debugged..*.*(..))", throwing = "e")
      public void myAfterThrowing(JoinPoint joinPoint, Throwable e) {

        Signature signature = joinPoint.getSignature();
        String methodName = signature.getName();
        String stuff = signature.toString();
        String arguments = Arrays.toString(joinPoint.getArgs());
        System.err.println("EXCEPTION THROWN:  "   + methodName + " with arguments\n "
          
            + arguments + "\nand the full toString: " + stuff + "\nthe exception is: "
            + e.getMessage());
      }
}

This adds an aspect that is executed after an exception has been thrown. It will print a string representation of the method’s arguments. If the exception is propagated, the arguments of all methods up the call stack will be printed in sequence.

I proudly announce the official release of ChemClipse 0.7.0!
https://projects.eclipse.org/projects/technology.chemclipse/downloads

But hey, what’s the difference between OpenChrom and ChemClipse?
It’s quite simple: There’s no difference. ChemClipse is the base for the OpenChrom Community and Enterprise Edition. One could compare it to the strategy RedHat runs. ChemClipse is the equivalent to Fedora and the OpenChrom Enterprise Edition the equivalent to RHEL. We as a company have a strong open source and collaboration commitment. We try to migrate as much of our code as possible to the Eclipse Foundation. Currently, we use the following setup:

• ChemClipse (IP reviewed code and release)
• OpenChrom Community Edition (Incubator for new collaborations and projects)
• OpenChrom Enterprise Edition (Commercial service and support for laboratories/customers)

Also have a look at our new blog:
https://spectrometrylab.wordpress.com

The VIATRA project is happy to report that release 1.4.0 is now available with multiple new features and fixed bugs.

The most notable highlights of this VIATRA release include:

• Local Search-based model query evaluation: In order to execute model queries with a smaller memory footprint, an alternative query backend was enabled. For backwards compatibility, this search-based backend is not turned on by default, but has to be requested manually.
• Development environment updates: The update of the query and transformation development environment has continued during this release, and the new views are now the recommended way to use for debugging model queries.
• Query Language Updates: In version 1.4 the query language was extended with a set of new features, most notable the support for aggregators, such as sum or min, or the explicit specification of the required query backend.

For a more complete list of changes, see the dedicated New and noteworthy page, or have a look at the list of fixed issues.

All downloads are available now from the downloads area or the marketplace.

Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions, we will not leave any unanswered. You can also request industrial support for more advanced issues.

Xtext derives a metamodel from the grammar file by default. For more complex languages it is often better to define the metamodel manually since it allows much more control over the AST, the abstract syntax tree. The metamodel has to be an EMF metamodel, which could be defined in Ecore or Xcore. In this article I will show you the setup to build the model project and how to integrate it into the project build.

The Xcore SDK allows to define the metamodel in a DSL which has some advantages against the definition in Ecore. However, using Xcore adds some complexity to the toolchain. Some of these implications are adressed by Holger Schill's presentation "Using Xcore models with Xtext". The presentation also covers the build integration aspect, but with Maven and with the "old" Xtext generator workflows.

Nowadays often Gradle is chosen as the build system to use. The new Xtext project wizard introduced with Xtext 2.9 allows to choose Gradle as the build system and produces the necessary build files for the projects. When using Xtext's web integration it is even mandatory at this time to use Gradle.

The problem now is that when an Xcore metamodel should be used, there is not much known on how to integrate Xcore in a Gradle build. At GitHub there is a xcore-gradle-example, but this only works with Gradle 2.7 and not with the current version 3.1. Further, it uses the old Xtext gradle plugin and not the new Xtext Builder Plugin.

This article shows an example which uses the following technology stack:

• Xtext 2.10
• Gradle 3.1
• Xcore 1.3.1

All sources are available in our GitHub repository.

Project Creation

As a reference the default "Greeting DSL" is used which is produced by the Xtext project wizard. The following options where chosen on the Advanced Xtext Configuration page:

• Web Integration
• Generic IDE Support
• Preferred Build System: Gradle

This creates the following projects:

org.eclipse.example.mydsl.parent
|
+--org.eclipse.example.mydsl
|
+--org.eclipse.example.mydsl.ide
|
+--org.eclipse.example.mydsl.web

For the parent project the latest gradle wrapper was added:

gradle wrapper --gradle-version 3.1

Model Project

The Xcore model should be defined in a separate subproject org.eclipse.example.mydsl.model. The new project is added as a subproject to the settings.gradle of the parent project:

include 'org.xtext.example.mydsl.model' include 'org.xtext.example.mydsl' ... >

It contains the Xcore model mydsl.xcore in the folder src. The declared metamodel is equivalent to the one that Xtext would generate from the grammar definition:

@Ecore(nsPrefix="mydsl",nsURI="http://www.xtext.org/example/mydsl/MyDsl")
@GenModel(
    bundleManifest="false",
    modelDirectory="org.xtext.example.mydsl.model/build/xcore/main", 
    complianceLevel="8.0"
)
package org.xtext.example.mydsl

class Model {
    contains Greeting[] greetings
}

class Greeting {
    String name
}

Note that the model directory is org.xtext.example.mydsl.model/build/xcore/main. This directory is added as a source folder to the project.

To build the project with Gradle the following build.gradle is used:

dependencies {
    compile "org.eclipse.xtext:org.eclipse.xtext:${xtextVersion}"
    compile "org.eclipse.xtext:org.eclipse.xtext.xbase:${xtextVersion}"
    compile 'org.eclipse.emf:org.eclipse.emf.ecore.xcore.lib:+'

    xtextLanguages 'org.eclipse.emf:org.eclipse.emf.ecore.xcore:+'
    xtextLanguages 'org.eclipse.emf:org.eclipse.emf.ecore.xcore.lib:+'
    xtextLanguages 'org.eclipse.emf:org.eclipse.emf.codegen.ecore:+'
    xtextLanguages 'org.eclipse.emf:org.eclipse.emf.codegen.ecore.xtext:+'
    xtextLanguages "org.eclipse.xtext:org.eclipse.xtext.ecore:${xtextVersion}"

}

sourceSets {
    main {
        resources {
            exclude '**/*.xcore'
        }
    }
}

xtext {
    version = "${xtextVersion}"
    languages {
        ecore {
            setup = 'org.eclipse.xtext.ecore.EcoreSupport'
        }
        codegen {
            setup = 'org.eclipse.emf.codegen.ecore.xtext.GenModelSupport'
        }
        xcore {
            setup = 'org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup'
            generator.outlet.producesJava = true
        }
    }
}

The main part is the configuration of the xtext-builder-plugin. EcoreSupport and GenModelSupport have to be added as languages, since they are used by Xcore. For Xcore the producesJava flag has to be set, so that the produced Java classes are compiled and packaged in the resulting jar file.

In the sourceSets section .xcore files are excluded from resources. Without that setting Gradle would copy the .xcore file during the build and within Eclipse there would be unwanted duplication errors.

Runtime Project

In the DSL runtime project we have to make some changes in order to use the metamodel defined with Xcore.

build.gradle

First, a build dependency has to be added to the build.gradle file:

dependencies {
    compile project(':org.xtext.example.mydsl.model')
    ...
}

Next, two additional dependencies have to be added to the mwe2 configuration:

dependencies {
    mwe2 "org.eclipse.emf:org.eclipse.emf.mwe2.launch:2.8.3"
    mwe2 "org.eclipse.xtext:org.eclipse.xtext.xtext.generator:${xtextVersion}"
    // added for Xcore support
    mwe2 'org.eclipse.emf:org.eclipse.emf.ecore.xcore:+'
    mwe2 'org.eclipse.emf:org.eclipse.emf.codegen.ecore.xtext:+'
}

DSL Grammar

Since the grammar's metamodel should not be generated anymore the grammar definition MyDsl.xtext has to be changed slightly. Instead of declaring the Ecore package to generate, we import it:

grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals

import "http://www.xtext.org/example/mydsl/MyDsl"

Model:
    greetings+=Greeting*;

Greeting:
    'Hello' name=ID '!';

Xtext Generator Workflow

Also the generator workflow file GenerateMyDsl.mwe2 has to be changed to use the manually defined metamodel.

First, the model project org.xtext.example.mydsl.model is declared using a project mapping:

bean = org.eclipse.emf.mwe.utils.StandaloneSetup {
    projectMapping = {
        path = "${rootPath}/org.xtext.example.mydsl.model"
        projectName = "org.xtext.example.mydsl.model"
    }
}

This is required in order to reference the mydsl.xcore file later with a platform resource URI. Without this registration, the platform URI cannot be mapped. The mydsl.xcore file is now declared as a referencedResource for the MyDSL language configuration:

language = StandardLanguage {
    name = "org.xtext.example.mydsl.MyDsl"
    fileExtensions = "mydsl"

    referencedResource = "platform:/resource/org.xtext.example.mydsl.model/src/mydsl.xcore"
    ...
}

Standalone Setup

When not using the DSL in the context of an Eclipse plugin, the metamodel's EPackage has to be registered in the EPackage registry. For the case that the metamodel is automatically generated, Xtext takes care of that registration in the generated base class of the DSL's standalone setup class.

Since the metamodel is not automatically registered in the case that it defines manually, the standalone setup class MyDslStandaloneSetup has to be extended to do the registration process explicitly:

class MyDslStandaloneSetup extends MyDslStandaloneSetupGenerated {

    def static void doSetup() {
        new MyDslStandaloneSetup().createInjectorAndDoEMFRegistration()
    }

    override register(Injector injector) {
        if (!EPackage.Registry.INSTANCE.containsKey(MydslPackage.eNS_URI)) {
            EPackage.Registry.INSTANCE.put(MydslPackage.eNS_URI, MydslPackage.eINSTANCE);
        }
        super.register(injector)
    }
}

Overview

The following image shows the resulting project structure with the files mydsl.xcore, MyDsl.xtext and GenerateMyDsl.mwe2:

Conclusion

Using an Xcore metamodel for an Xtext grammar requires an additional subproject which holds the Xcore definition. The article showed the necessary setup to build the model project with Gradle and integrate it into the project build.

Some additional changes have to be done to the Xtext grammar to use the predefined metamodel and to integrate it into Xtext's generator workflow, but it's worth the effort especially when it comes to more complex languages.

The Gradle build configuration is a bit tricky, but taking this project as a reference it should be mostly copy/paste work.

Following my recent series of articles about the Eclipse Marketplace Client, I have recorded a short video tutorial to show you how to use favourites lists on Eclipse.org and in Eclipse:

• Add / remove plugins in your favourites list on marketplace.eclipse.org
• Add / remove plugins in your favourites list with the Eclipse Marketplace Client
• Import the favourites list from an Eclipse Community user in the Marketplace Client
• Share your favourites

Here are a few favourites lists that I would like to share with you. You can import them directly by copying and pasting the link in Eclipse Marketplace Client:

• Java – Lars Vogel
  https://marketplace.eclipse.org/user/lvogel/favorites
• C / C++ – Doug Schaefer
  https://marketplace.eclipse.org/user/dschaefer/favorites
• Modelling (Sirius) – Cédric Brun
  https://marketplace.eclipse.org/user/cbrun/favorites

So? What are your favourite plugins and packages on Eclipse Marketplace? Build your list, and share it with your team. We encourage you to share your lists with us on Twitter using #EclipseMarketplace.

Watch the video on Youtube:

More news

We are happy to announce that together with Neon, we have released  EMF Forms and EMF Client Platform 1.10.0!

We want to thank all committers and contributors for their work as well as the active ecosystem of users and adopters for the feedback and support!

Both projects have been amazing successes since their inception over 5 years ago. We are proud of having a continuously active team of 12 contributors and 33 contributors over all.

EMF Forms is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for a introduction.

Both frameworks are part of Eclipse Modeling Tools Neon.1, but you can also find the new release on our download pages:

• Download EMF Client Platform
• Download EMF Forms

We will give a talk at EclipseCon Europe 2016 also introducing the new features, so make sure you register soon.

You might have noticed, that we have started on a new renderer for EMF Forms based on a native web stack (using AngularJS and JSON Schema) called JSON Forms. We see it as the optimal complement for EMF Forms and hope to make the idea of declarative UI development even more attractive. We are amazed by the progress of JSON Forms and we will soon start a blog series to introduce it more in detail in November. Even earlier you can get more details about JSON Forms in our talk at EclipseCon Europe on October 27th – More forms – less </code>.

However, as you can see in the EMF Forms / ECP repository, we have not in any way reduced our effort for the existing frameworks and do not have any plans to do so.

As always, we will also blog about new features of the EMF Forms / ECP 1.10.0 release in the upcoming weeks! Please follow this blog or follow us on twitter to get notified about the new posts.

I would like to welcome Sergey in the Eclipse Project Management Committee (PMC) for the Eclipse Top Level Project.

I think of Sergey as a friend and I’m very happy that he joins our team. Based on what I have seen of his work in Platform UI, he focuses on clean and easy to use API, code cleanup and process simplifications. Sergey contributed the UI freeze monitor and together with his team (most notable Stefan Xenos) he works on improving the interactive performance of the Eclipse IDE.

Welcome Sergey!