In my last post I started explaining how one can write a so called forward compat layer for a custom application.

In the blog post I’ll present the first available bits of such a layer provided as part of the e4-Tooling effort. The idea of the forward compat layer is that you use the e4-Programming Model and write pure e4 POJOs which can be hosted inside an 3.x/4.0 workbench. Let’s at first look at the big picture how an e4-Application and 4.0 Workbench look like.

A pure e4-Application looks like this:

A 4.0 SDK with the backward layer like this:

An 3.x/4.0 SDK with Forward Compat Layer like this:

As the picture shows, the idea in the forward compat layer is to setup an DI-Container in a running 3.x Workbench and reusing the DI-Container provided in a 4.0-SDK Workbench.

Now that we know the background how can we work with it. The first thing to do is to write a Simple POJO which use an OSGi-Service of the type ITranslatorProvider:

package at.bestsolution.translate.view;

import javax.inject.Inject;
import org.eclipse.e4.core.di.annotations.Optional;

import org.eclipse.swt.widgets.Composite;
import at.bestsolution.translate.services.ITranslatorProvider;

public class TranslatorComponent {
  @Inject
  public TranslatorComponent(Composite parent) {
    createUI(parent);
  }

  @Inject
  void setTranslationProvider(@Optional ITranslatorProvider provider) {
    // Get the OSGi-Service injected    
  }
}

You should notice that the only “framework”-code we are depdending on is a bundle which defines the annotation we are using. Typically the components are kept in an extra bundle which has only dependencies on DI-Stuff.

If we want to integrate ourselves into a 3.x/4.0 SDK we somehow need to register our POJO in the DI-Container which is done in an e4-World by the ApplicationModel.

To register our View/EditorPOJO we are using specialized containers named DIViewPart/DIEditorPart like this:

public class TranslatorView extends DIViewPart<TranslatorComponent> {
   public TranslatorView() {
     super(TranslatorComponent.class);
   }
}

which itself is registered in the 3.x/4.0 Workbench using the views-extension point:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <extension
         point="org.eclipse.ui.views">
      <category
            name="Utilities"
            id="at.bestsolution.translate.view">
      </category>
      <view
            name="Translator View"
            icon="icons/page_find.png"
            category="at.bestsolution.translate.view"
            class="at.bestsolution.translate.view.TranslatorView"
            id="at.bestsolution.translate.view.TranslatorView">
      </view>
   </extension>

</plugin>

The 3.x/4.0 integration is typically kept in a bundle which depends on the bundle with the component(s) and the standard set of 3.x plugins like (org.eclipse.ui, …).