Kategorie-Archiv: Eclipse

Articles concernig Eclipse, mostly dedicated to the new Eclipse 4 system

JFace Databinding with PojoProperties on Boolean

Consider the following Pojo Foo

public class Foo {
  boolean boolProp;

  public void setBoolProp(boolean boolProp){
    this.boolProp = boolProp;

  public boolean isBoolProp() {
    return boolProp;

then you might assume, that you can databind that with master-detail pattern given a SWT.Button with the following code

IObservableValue uiObs = WidgetProperties.selection().observe(button);
IObservableValue prescObs = PojoProperties.value("boolProp", Boolean.class).
dbc.bindValue(uiObs, prescObs);

Well this will not work, you actually have to have a method

  public boolean getBoolProp() {
    return isBoolProp();

in your Pojo to make it work.

I am not sure, why this is the case, as one tries to programm according to bean style, where you have the isX and setX for Boolean properties. I am also not sure wether this is different for newer versions of JFace (this is 3.8.0). Just find it worth mentioning, and am hoping for some comments on this :)

Oomph and github pull request task lists

After Eds and Eikes nice talk on Oomph at EclipseCon 2014, I decided to give it another try for our Elexis project. Turns out that its a bit tricky to come in.

One thing is that I want to configure the pull requests available in the github repo as tasks within Eclipse, and this is what I did to do so


I found out about the correct connector kind when diving into my workspaces .metadata/.mylyn directory having a look at repositories.xml.zip. This also showed me that I have to add the attribute state=open:: in order to have fully configured task lists on the open pull requests.

e4: Updating UI contributions on context switch

During the implementation of a new project, I want to harness the capabilities of the Eclipse application model when it comes to changes in the Eclipse context, or more accurate the de-/activation of context specific handlers.

What does that mean? Lets have a look at the following application model:

contextswitchmodel1 is the global definition of our testCommand, 2 and 3 are perspectives in our application where for the given command a separate handler gets activated due to the context switch from perspectiveA to perspectiveB and vice-versa. 4 is the UI contribution of the command visible to the user in the top window trim.

The resulting application looks like testAppshown on the left hand side. Where the UIContribution 4 is marked with a red arrow. Now the task of the handlers is to toggle between the perspectives and update the UI contribution to either show perspectiveA or perspectiveB.

As described in stackoverflow and the Eclipse forum I did not, at first, find an obvious approach to this (remark in Eclipse 3.x this could be implemented by using an IElementUpdater). After some more analysis I found a way to do so. The source for the following example is certainly available.

Lets fix the example by having a look at HandlerA

public class HandlerA {
    public void execute(EPartService partService,
             EModelService modelService, MApplication application) {
        MPerspective perspective = (MPerspective) modelService.find(
                "perspectiveB", application);

    public void bla(
            @Optional @Active @Named("handler::testCommand") Object value,
            EModelService modelService, MApplication application) {
        if (value == null)
        List<MHandledItem> findElements = modelService.findElements(
                application, null, MHandledItem.class, null);
        for (MHandledItem mHandledItem : findElements) {
            mHandledItem.setTooltip("perspectiveA now active");

The @Execute method does the simple task of toggling the perspective. The updating itself happens in lines 12-23. This method does listen to property changes of handler::testCommand which is the global command (see 1 in the above app model). Each time a context switch happens we get injected the current handler through Object value. So we may act accordingly. Here we act by using the modelService to find all contribution elements subsequently setting a new Label and Tooltip.

If more commands and handlers are in your application you should do a more intelligent search and/or filter on the value to act correct.

This approach, however, is not perfect, as you have to implement this method in both handlers in order to always be able to act upon the change. There are other feasible approaches like creating an Addon where you put the @Inject part, you would have to do this for each command separately, however.

I would prefer to be able to define a class within the MCommand element to put the respective code into which would always be notified in any change that happens related to it. So imagine that a MCommand has an option Class Uri and the respective referenced class could look like this

public class TestCommand {

    EModelService modelService;

    MApplication application;

    public void bla(@Optional @Active MHandler activeHandler,
            @Active MCommand command) {
        if (activeHandler == null)
        List<MHandledItem> findElements =
                application, null, MHandledItem.class, null);
        for (MHandledItem mHandledItem : findElements) {
            mHandledItem.setTooltip("perspectiveA now active");

Where the injection will happen on change of the activeHandler and I also get the MCommand itself injected. This way one could also efficiently store the given UiContribution elements and limit the searches ….

What do you think? Eager to hear your opinion :)

Setting Java for Eclipse on OS X …

It already bothered me for some time, that one constantly seems to have Eclipse running with the wrong Java version. That is, if you’re doing heavy development you might have Java 6, 7 and 8 installed on your machine.

In order to switch the main JVM Eclipse will run with you have to follow these instructions, which involves manually changing the .ini file each time you want to change the version. This is quite cumbersome, so I decided to learn some Apple Automator.

After some insatisfying approaches to generate a service, I generated an application that works as follows:

  1. Drag an OS X Eclipse.app onto it
  2. The application browses all JDK installations in /Library/Java/JavaVirtualMachines and prompts you to select one, which it will then configure within the resp. ini file

The app is completely realized in Automator, with some perl, I had to zip it to distribute it over Dropbox. It is in a very early stage … feedback always welcome :) Here goes a short demo video:

Horizontal extending the application model editor

With this commit the functionality to extend the Application model editor is augmented to allow for horizontal extension of its elements. So what does this mean?

Lars describes in his tutorial how to vertically extend the application model, that is, how to add additional model elements and provide a respective editor for it. But what if I want additional editing capabilities to already existing model elements like e.g. the command element?

This is where the new extension point org.eclipse.e4.tools.emf.ui.editors.editorTab comes into play. The following image shows an example of the current usage within the Écrit project:

horizontal extension point with and without
horizontal extension point with and without

We added the possibility to augment existing model elements with additional documentation artifacts – but this will become part of another blog (series) 😉

Back to the extension point. In order to use it you have to first extend this new extension point, directing it to a class extending org.eclipse.e4.tools.emf.ui.common.AbstractElementEditorContribution:

editorTab EP
editorTab EP

This class may look like

import org.eclipse.core.databinding.observable.value.WritableValue;
import org.eclipse.core.resources.IProject;
import org.eclipse.e4.tools.emf.ui.common.AbstractElementEditorContribution;
import org.eclipse.e4.ui.model.application.commands.MCommand;
import org.eclipse.emf.databinding.EMFDataBindingContext;
import org.eclipse.emf.edit.domain.EditingDomain;
import org.eclipse.swt.widgets.Composite;

public class blaClass extends AbstractElementEditorContribution {

public void createContributedEditorTab(Composite arg0,
EMFDataBindingContext arg1, WritableValue arg2, EditingDomain arg3,
IProject arg4) {
// create the editor tab in here

public Class<?> getContributableTo() {
return MCommand.class;

public String getTabLabel() {
return "myNewTab";

The getContributableTo denotes to what model elements the editorTab will be added (this is determined as you returned Class must be instanceof).

If you want to have a look at a more specific example, take a look at the Écrit implementation of the extension point.

Questions, comments? :)

Exporting model element ids

In order to address model elements out of the application model itsef, and out of contributing classes, the resp. model element id is used. During development you often run into errors because of wrong id strings.

To mitigate this problem a new action, called  Export Model Ids is now available within the e4 tooling starting with this build.

Popup-Menu Command Export Element Id

On execution it selects all the element ids available within the application model, and presents it to the user:

Export Id Handler Dialog

In this table you see the type of element, the static key it is gonna have in the resulting java class, and the original id. Currently the key is built out of the element type and the element id.

After execution you should find a java file called AppModelId.java, probably containing some errors due to you using duplicate ids, such as in the following image:

ExportIdHandler OutputClass AppModelId.java

There are several things I would like to change to this feature, but it seems a good start – thanks a lot to Wim for the feedbacks and reviews!

Things I would like to add/change in the future

  • make the output class, package and project selectable (currently this would introduce too much dependencies)
  • care for double occuring ids
  • make subtrees of the application model exportable (currently the whole app model ids are exported)
  • perform automatically configurable update of the target file(s)
  • remove dependency to org.eclipse.jdt.core

If you have any other feedback or comments, please put them on here!

Programmatically load an Application.e4xmi

In case you were wondering or struggling, just like me, how one could possibly load an Application.e4xmi file out of a standalone Java application, here goes some code for you :)

import org.eclipse.e4.ui.internal.workbench.E4XMIResourceFactory;
 import org.eclipse.e4.ui.model.application.MApplication;
 import org.eclipse.e4.ui.model.application.impl.ApplicationPackageImpl;
 import org.eclipse.emf.common.util.URI;
 import org.eclipse.emf.ecore.resource.Resource;
 import org.eclipse.emf.ecore.resource.ResourceSet;
 import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;

public class LoadAppModel {

private static ResourceSet resourceSet = new ResourceSetImpl();

public static void main(String[] args) {
 URI uri = URI

 .put("e4xmi", new E4XMIResourceFactory());

Resource res = resourceSet.getResource(uri, true);
 MApplication app = (MApplication) res.getContents().get(0);


Be sure to include all the required bundles, especially in the OSGI context.

Update I just came up to a nasty problem: If you repeatedly iterate your application model, while modifying it, you need to be sure to unload the model each time you are done, otherwise lazy loading will not pick up the changes, as the model is already loaded.

To depict this I added the unload method to the code sample.


Synchronising stateful items … [part1]

I’ve been banging my head some time now (which can be seen in Bug 397249) on the problem of sychronizing stateful Eclipse 4 application model items with the code.

Wait, let me set the scene first: The Items I am talking about are either Direct or Handled, Menu or Tool, Items added to either a Menu or a Toolbar in the application model. And by stateful I mean the requirements of Items of type Check or Radio to have their state synchronized with the state of the application.

Statefullness requires a Command connection

Overall stateful usage of items is bound to being connected with a Command, hence all items of type Direct are generally not considered for stateful usage. They should be used with check type only, for one shot execution of whatever you might deem necessary.

I, however, see a feasible way to use them in Type.Check which might be handy to you. In order to update the state of a Type.CHECK Direct*Item, simply use the @CanExecute annotation for a method in your contribution_uri class like this:

public boolean canExecute(MItem element) {
  return true;

@CanExecute is called everytime your element is to be shown. It allows you to update the availability of your action according to your settings, and you may also use it to update the state.

Using Direct*Items is good for smaller tasks, but one must not forget, that using this element the model has to access the implementing class to query the state. This may lead to lazy plug-ins being started just to gather the information about the availability resp. state.

Stateful Handled*Item

In order to use Handled*Items, a method (not in the code meaning but literal) is required to initialize the state of your Type.CHECK and Type.RADIO items at startup to the state of your code.

Let’s consider this for both Type.CHECK and Type.RADIO. Lets fix an example of a viewer (yes, just like this SWT TableViewer example) showing a set of Persons being either male or female. A person may also be married, single or widowed.

The Type.CHECK items in the filter will be the boolean representation of showOnlyMale in Handler, which sets it into the state to show only male persons.

The Type.RADIO items will allow us to show married, single or all persons. Here we have three contribution items which together form a radio group.

It is important that the items allowing us to select the states will be present more than once but connected to the same command. The following image depicts this:


The code is implemented in the Handler part, while the model is being represented by all none code parts, that is the Command and the multiple ContributionItems.

One may set the isSelected feature of the Contribution items within the application model, they are, however, not being synced to the state of the Handler (i.e. the Filter in our example) and vice versa (how should they, Eclipse does not know about the connection).

So first the question arises, whether the model should synchronize to the code, or the code to the model for this cases?