Eclipse 4.0 and tutorial on writing e4-RCP-application released

The Release

The e4-Team just announced the availability of the Eclipse 4.0 SDK “Early Adopter Release” (Reviewslides) which marks a major platform update since the inception of 3.0 6 years ago.

Just to reiterate what the 4.0 SDK is and to set expectations right. The 4.0 SDK is marked as an “Early adopter release” targeted at Plug-in Developers who want to test their code on the upcoming 4.x platform and report problems because of broken APIs or “APIs” not available anymore because they used internals of the platform.

The 4.0 SDK “Early Adopter Release” is not targeted for use as your Primary IDE so keep this rough edges in mind when giving the 4.0 SDK a try.

When takeing a closer look to the release you’ll notice that in reality multiple different things have been released:

  • Eclipse 4.0:
    • Eclipse 4.0 Application Platform: The new application platform to write OSGi-base (UI-)Applications centered around a new programming model using DI and a modeled application kernel
    • Eclipse 4.0 Compatible Rich Client Platform: Compability layer for API clean 3.x bundles to run unmodified on the new Application Platform
    • Eclipse 4.0 SDK: Eclipse 4.0 Application Platform + Eclipse 4.0 Compatible Rich Client Platform + PDE 3.6 + JDT 3.6
  • Eclipse 4.0 Technologies (also called “e4 SDK 0.10” / “e4 release July 2010” because the releasing project is e4):
    • XWT + Tooling: XAML for SWT/JFace and Visual Designer Tools
    • Semantic Filesystem implementation
    • Application Modeltooling

A small hint for Plug-in developers who are trying to debug their Plug-In by launching an inner Eclipse and all Eclipse 4.0 Application-Developers. The Eclipse 4.0 SDK misses at the moment the source bundles for the new Eclipse 4.0 components and you need to install it through the p2-repositories pre configured for you.

We recommend to install:

  • Modeled Workbench Source
  • CSS Support Source

to successfully step through the code using the debugger.

My personal main focus in the Eclipse 4.0 development for the last 2 years has been the “Eclipse 4.0 Application Platform” whose goal is to modernize and simplify the development of OSGi-based UI-Application using DI and a modeled application approach. In the last few months I also worked on a tool to make writing applications for the Eclipse 4.0 Application Platform easier.

The model tooling

Since March I’ve been dedicated half of my 4.0 development time implementing support for the application model underpinning the Eclipse 4.0 Application Platform.

The model tooling has not yet graduated out of the e4-incubator and so is not part of the Eclipse 4.0 SDK download and you’ll have to install it using the preconfigured e4-repository – you find it in the “E4 Tools”-category.

The tooling is working in 2 modes:

  • Design/Development-Time mode: This is the standard mode you are using when developing an application. In this mode you operate on a Application-Model persisted as a XMI-File in your workspace.
  • Live mode: In this mode you are operating on the live model of a running application and are able to inspect and modify live

The Eclipse 4.0 Modeltooling is written to run native on the Eclipse 4.0 Application Platform (no useage of the Backward-Compat-Layer) but also integrates smoothly in the Eclipse 4.0 SDK.

Probably one of the most remarkable things though is that it runs also in a 3.6 SDK enabled by the so called Forward Compat Layer I started developing who does the opposite of the backward-compat-layer. It allows you to run components using the Eclipse 4.0 Progamming model which is built upon POJOs and DI in a 3.6 environment.

This makes it possible to write Eclipse 4.0 Applications using the 3.6 SDK as the screenshot demonstrates:

All you need is to install the tools using the e4 Update Site which is available on

The tutorial

When introducing new technologies we know that it is important to give people a medium sized example application which explains the concepts of the framework and provides them “monkey see, monkey do” example code. That’s why I’ve worked in the last few days/weeks on a tutorial which helps people getting started writing applications using the “Eclipse 4.0 Application Platform”

You can download the tutorial which is released under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 using this link. The sources codes are released under EDL-1.0/EPL-1.0 and are available from github and/or as individual zips (urls found in the PDF).

If you only want to take a look at an application built using the Eclipse 4.0 Application Platform you can downloaded using the links below:

You need Java 6 to run the demo although Eclipse 4.0 itself only needs Java5. To get accounts displayed on the left you should enter the following values in the Preference Dialog:

  • Username: john
  • Password: doe
  • Host:

It looks like the update-code triggering of the AccountView is a bit weak so if you are not informed about the opening of the session after clicking around stop and starting the application should help you (I’ll try to work on a solution in the days to come).

Just in case you like the service I’m providing to you for free with this tutorial and you want to donate some cents here’s the button to push:


  • 2010-08-10:
    • Fixed unclear section on page 6
    • Added warning to not install Visual WorkbenchTooling

Writing RCP Applications with e4

Now the 4.0 release is approaching very fast and I’ve been working full(free)time on an extended tutorial writing an e4-RCP-Applications.

The whole tutorial is centered around an exemplary Mail-Application

I’ll release the tutorial and the whole source on the day we release the 4.0 SDK so if all works out as we expect and you check back here on Wednesday/Thursday you’ll find a complete e4 tutorial helping you to get started with e4:

Topics covered:

  • Install tooling coming with e4
  • Getting started with the e4-Application model
  • Getting started with the e4-Programming model based upon Pojos, DI and OSGi-Services
  • Using CSS to style your Application
  • Manipulating the e4-Application model in a running application

p2 I love you

Last week I had the joy to add self-updating to one of our customers RCP-Application and well it turned out that this task only lasted for about 2 hours beside reading through the p2-Docs on the wiki and other online blogs which took me some more time.

To keep this post as short as it took me to add p2 to the 3.5 application. It simply worked out of the box. I’m now customizing and tweaking it here and there but I’m quite postive this will work out also smooth.

e4 – Some more news from the modeltooling

Fragment Tooling

As you might see with the number of posts. I’ve been hacking a lot my ModelTooling-Editor and so after having talked about the latest features 3 days ago, I have some more news today.

I’ve spend half of my yesterdays evening improving the ModelFragment-Tooling.

For those not familiar with e4 and the workbench model this might not be clear so I’ll explain in short what ModelFragements are:

I guess most of you are familiar with 3.x and know how you contribute a view, editor, command, menu, … you use the matching extension point (e.g. org.eclipse.ui.views). The definition of the Meta-Model (or better said the various attributes you can define for a contributed elements) are defined in various .exsd files who can only use IDs to connected to each other (e.g. to connect a Menu-Contribution to a Command and Handler to a Command).

A view contribution looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>


All those extension definitions are collected when your 3.x Application (the Eclipse SDK is nothing more than that) is started and converted in so called descriptors, stored in registries (e.g. IViewRegistry) which can be accessed like this:

IViewDescriptor desc = PlatformUI.getWorkbench().getViewRegistry().find("ContactsView");

and used internally to make up workbench, with its ViewParts, EditorParts, Menus, … but the descriptors have no reference to each other (e.g. the menu item descriptor contributed to a views menu has no idea about view-descriptor, …) their relationship is a purely virtual one made up inside the workbench and defined through ids (so there’s no picture I can show you at this point).

The situation in an e4-Application is completely different. The workbench itself defines a concrete model which defines the relation ship between the different parts of the system and this model is used by the workbench to make up your complete application (from the command to the handler to the parts (=editor and view) to the menu item …).

Here’s a screenshot of a running application:

The problem we are now having is how this running application is constructed. For small applications who are not created out of many different individual parts one can define the application up-front and simply start up with this monolithic model but this would obviously not work for things like the Eclipse SDK which is made of from many different more or less independent OSGi-Bundles.

Now you could think that this is exactly where the well known extension points from 3.x could come into play because they allow to make up an application from those independent bundles and to some extend you are right this is possible or better exactly what the compat layer is doing. It takes all you extension points and makes up an application model like this:

But this is not ideal because now that the application itself defines already the Meta-Model (attributes, containments, references, …) its not making sense to have 2 systems who define how the contributed data looks like beside the fact that you’ve never been able to contribute e.g. the layout of a perspective but this information has been made up in IPerspectiveFactory using Java-Code.

So we came up with another solution we named ModelFragments who themselves use the the Meta-Model which was used to define the workbench model itself. All you need to know is one extension point named “org.eclipse.e4.workbench.model” which allows you to contribute fragments to an existing base model.

The problem from the tooling side of this that you need to reference elements in the base model using IDs and the tooling need to help you looking them up in the available base models and other fragments (yes fragments can point to other fragments :-). So what’s needed is a way to look up and find all of those models in a workspace and provide the user with a dialog to select the appropriate element he’d like to reference when contributing.

There are 2 types of references used in our new contribution story:

Referencing a parent element:

This is the more obvious use case where you want to contribute a childelement to an existing container. Take a look at the following Model:

If we’d like to contribute a Part-Element below the selected stack “all” we need to do is to reference the parent element and define below which feature we’d like to contribute our Part-Fragment.

At this moment the new tooling I added helps you finding the correct place and element you’ll want to contribute to.

Find the correct parent id:

This dialog helps you finding the appropriate parent-id which acts as the container for your contributed element.

Find the correct attribute:

This dialog helps you to find the correct attribute-name into which your element is stored in.

Referencing another element:

The second area where you need to reference is more subtle but very important also. An example for it is that you’d like to contribute a keybinding for a command not defined by yourself but someone else. Here’s the base model where our keybinding should take place:

You see that we need to contribute a (Key)Binding below the BindingTable with the Id “org.eclipse.ui.contexts.dialogAndWindow”. So we do exactly what we did above and come up with the following:

but this is not enough a KeyBinding needs to reference the command the keybinding is connected to! Remember what I said above how the model internally is working. It is using Java-References and not those weak ID-References from 3.x. So looking at the Keybinding-Editor we notice that we need to somehow reference the command instance but apparently the fragment doesn’t hold such a reference.

So we are in trouble now that e4 is not using id-references but strong ones (EMF people now might say that we should use cross-references between models but without going into detail is not solving our problem – you can read in depth discussion on this bug).

The solution we use is that we allow you to create imports inside the model fragment which uses IDs to reference the real elements definition which gives you a instance of the element at design time and at runtime when the model is put together those import-elements are replaced by the real ones.

Here a similar new ID-dialog has been added allowing you to search for ids you’d like to import:

If we now reopen the Command Dialog we are able to select the command we want to connect our binding to:

ToBeRendered and Visible-Attributes

Eric Moffatt pointed me to the fact that we the model editor is not able to edit 2 important fields of our UI-Elements (visible/toBeRendered) and promised an extra bonus when they they show up in gray in the tree on the left.

Drag&Drop and C&P between files

I think don’t have to explain this. You can now drag and drop and copy and paste elements from model files to model files. This is quite nice e.g. to add imports without using the Find-Dialog.

e4 – News from the model tooling

I’ve been busy working on my model editor and some wizards to create Java-Classes for our new programming model.

New features in the model editor

  • New Drag&Drop Support in the Left Tree: You can now drag around items in the tree to reorder them
  • Support for Copy, Paste and Cut: You can now use the common known Keyboard-Shortcuts CTRL (CMD)+C,V,X
  • Open a contribution implementation: Contributions like Handlers, Part and Addon can now open the class having the implementation can be opened with one click
  • Create a contribution class through a wizard: By clicking the same Link-Label as above with no current contribution you get presented a wizard to create a typical implementation for the given contribution type.

e4 Wizards

The second important thing is that I added a set of new wizards who allow you to create an e4-Application (I factored this out from Yves cool Visual E4 Workbench Model Designer) and individual parts of it of an e4 application.

  • Model
    • Create an Application-Model: As you might already know an e4-Application from a simple RCP to the fullblown Eclipse SDK stores all relevant informations inside one place named application model
    • Create an Application-Model-Fragment: A model fragement can be compared to what you do today using the various extension points (views,editors,menus, commands, ….) but because the workbench itself already defined the types it is working with (incontrast to 3.x) you use 100% the same entities to contribute to the model. This allows you to make up an application model from various different bundles who contribute fragments.
  • Classes
    • New Addon Class: An addon is a none visual contribution who typically only wants to plug itself in the to EventBus of an application
    • New Handler Class: A class which is executing a business logic when a user action is triggered by a command or a direct menu or toolbar item
    • New Part Class: A class who is responsible to make up the content of a Part in your application (e.g. the JavaEditor, PackageExplorer, …)