Tomsondev Blog

Today I extended my current implementation a bit so that I now extract the currently injected fields in a class and display them in the dialog one can open from within the JavaEditor. The following videos present shows this in action.

The next step is to add injected services through the Dialog. People asked in comments of the last post whether this support is isolated to e4 and it’s services and the answer is no. The current implementation simply registers a service in the OSGi-ServiceRegistry.

public interface IDIServiceRegistry {
  public void addServiceProvider(IDIServiceProvider descriptor);
  public void removeServiceProvider(IDIServiceProvider descriptor);
  public List<IDIServiceProvider> getProviders();
}

Potential Tool implementors can use and provide informations about available services who are probably available at runtime. As an example implementation I’ve implemented 2 example bundles who contribute providers for e4-core services using DS (you see in the screencast that no available services are there until the tooling bundles are started).

The contribution of the Logger-Service is done looks like this:

public class LoggerProvider extends DIServiceProvider implements IDIServiceProvider {
  public LoggerProvider() {
    System.err.println("Instance created");
  }

  public String getLabel() {
    return "Logger Service";
  }

  public String getDescription() {
    return "Logging warnings, errors, information, as well as capturing debug and trace information. Everything done through this interface is not meant for normal end users. Strings are not expected to be translated.";
  }

  public String getServiceClassName() {
    return "org.eclipse.e4.core.services.Logger";
  }

  public String getBundle() {
    return "org.eclipse.e4.core.services";
  }

  public String getProduct() {
    return "e4";
  }

  public String getCategory() {
    return "Core Services";
  }
}

and contributed like this using DS:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component
  xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
  enabled="true"
  immediate="true"
  name="org.eclipse.e4.core.services.jdt">
   <implementation
     class="org.eclipse.e4.core.services.jdt.LoggerProvider"/>
   <service>
      <provide interface="org.eclipse.e4.ui.jdt.IDIServiceProvider"/>
   </service>
</scr:component>

After having implemented the Class-Modification. I think the next logic step would be to write some PDE-Addon which simply registers all available DS-Services found in the Target-Platform into the DI-Registry. I’m still in an experimental stage so probably this is all crap and one has to address the problem differently.

Anyways I’ve learned something about IJavaProject and the AST-Stuff coming with JDT and it’s been a lot of fun so far.

In bug 302824 we started discussing how to make the use of DI easier and beside e.g. providing Helper-Classes the ideal thing would be to provide good tooling. Think about how hard OSGi-Development would be without PDE and I think the same is true for DI as well.

I had some free minutes (well in reality hours) today and thought about how such a tooling could look like. The first thing I’ve implemented today is a dialog showing core services and add them to your POJO (currently only the UI is working more or less).

There are other JDT/PDE extension we could provide to make DI in general easier but I need to make myself familiar with PDE/JDT-extensions before I know what’s possible.

After some months of not having contributed substential stuff to e4 and in anticipation of the EclipseCon tutorial “e4 – Anatomy of an e4-Application”. I worked yesterday on some demo stuff which we’ll probably use show the audience:

• The new development process when writing plugins using Mock-Objects
• Extending an existing e4-Application

The idea of the extension is to add Flickr-Support (Searching and importing images and adding Images to flickr) to our e4-Photo-Demo using the Service-API provided by flickr.com.

One of the strengths of writing and extending e4-Applications is that you don’t need to bring up whole workbench but can develop all components standalone at first (you can even simply start with a none-OSGi-Application).

Here’s the process I followed

• Writing the UI as an ordinary SWT-Application (No OSGi, No e4). The initial code looked something like this:

  public class Flickr {
    public Flickr(Composite comp) {
       // Create my UI
    }
  
    private void handleSearch(String apiKey, String tags) {
      // TODO implement search logic
    }
  
    public static void main(String[] args) {
      Display display = new Display();
      Shell shell = new Shell();
  
      Flickr flickr = new Flickr(shell);
      shell.open();
  
      while( ! shell.isDisposed() ) {
        if( ! display.readAndDispatch() ) {
          display.sleep();
        }
      }
  
      display.dispose();
    }
  }
  

  After some codeing (well I thought writing something like a PagedTableViewer might me a nice thing) the UI looked like something like this:
  . The code is in a Bundle-Project “org.eclipse.e4.demo.e4photo.flickr” which depends on SWT-only for now (I let PDE manage even my standard Java-Project because this frees me from all the ClassPath-Configuration).

• The next thing was to look at the Flickr-API and what a JavaService to talk with it could look like. The Service-Interface I came up with looked like this:

  public interface IFlickrService {
    public FlickrSearch createTagSearch(String apiKey, String tags) throws RemoteException;
  
    public List<FlickrPhoto> getPhotos(FlickrSearch search, int page) throws RemoteException;
  
    public InputStream getPhoto(FlickrPhoto photo) throws RemoteException;
  }
  

  The service definition is also part of a separate bundle named ‘org.eclipse.e4.demo.e4photo.flickr.service’.

• Next step was to create a bundle with a concrete implementation named ‘org.eclipse.e4.demo.e4photo.flickr.service.rest’. Which uses the REST-API provided. The service is self is also a simply POJO and so I was able to test it quite easily by simply adding a main-method.

  public class RestFlickrService implements IFlickrService {
    // Implementation of methods
  
    public static void main(String[] args) {
      try {
        RestFlickrService s = new RestFlickrService();
        FlickrSearch search = s.createTagSearch("46d3d5269fe6513602b3f0f06d9e2b2e", "eclipsecon");
  
        for( int page = 1; page <= search.getPages(); page++ ) {
          System.err.println("--------------------------------");
          System.err.println("Page " + page);
          System.err.println("--------------------------------");
          List<FlickrPhoto> photos = s.getPhotos(search, page);
          for( FlickrPhoto p : photos ) {
            System.err.println("	* " + p);
          }
        }
      } catch (Exception e) {
        e.printStackTrace();
      }
    }
  }
  

  Please don’t blame me that I haven’t written this by creating JUnit-Test but you should get the point that writeing application like this makes your whole application very easy to test in a real world application.

• Now we need to wire the stuff together so until now we didn’t even used OSGi but now we can’t get away without it. First step is to use DS to register our service in the OSGi-Registry:

  <?xml version="1.0" encoding="UTF-8"?>
  <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="org.eclipse.e4.demo.e4photo.flickr.service.rest">
     <implementation class="org.eclipse.e4.demo.e4photo.flickr.service.rest.RestFlickrService"/>
     <service>
        <provide interface="org.eclipse.e4.demo.e4photo.flickr.service.IFlickrService"/>
     </service>
  </scr:component>
  

• And we need to make our UI-Bundle use the IFlickrService. To prepare the stuff for DI we need to add the javax.inject-Bundle which holds the annotation of JSR-330.

  public class Flickr {
    @Inject
    private IFlickrService flickrService;
  
    private void handleSearch(String apiKey, String tags) {
      try {
        FlickrSearch search = flickrService.createTagSearch(apiKey, tags);
        table.setInput(new SearchInput(search));
      } catch (RemoteException e1) {
        Status s = new Status(IStatus.ERROR, "org.eclipse.e4.demo.e4photo.flickr", e1.getMessage(), e1);
        ErrorDialog.openError(table.getShell(), "Searchfailure", "Failure while executing search", s);
      }
    }
  }
  

• Now we make an mock-application bundle ‘org.eclipse.e4.demo.e4photo.flickr.mock’ which holds an Equinox-Application which bootstraps the Dependency Framework coming with e4 and creates an instance of our view.

  public class Application implements IApplication {
    public Object start(IApplicationContext context) throws Exception {
      Display display = new Display();
      Shell shell = new Shell();
  
      Bundle bundle = FrameworkUtil.getBundle(Application.class);
      BundleContext bundleContext = bundle.getBundleContext();
      IEclipseContext eclipseCtx = EclipseContextFactory.getServiceContext(bundleContext);
      eclipseCtx.set(Composite.class.getName(), shell);
  
      ContextInjectionFactory.make(Flickr.class, eclipseCtx);
      shell.open();
  
      while( ! shell.isDisposed() ) {
        if( ! display.readAndDispatch() ) {
          display.sleep();
        }
      }
      display.dispose();
      return IApplication.EXIT_OK;
    }
  
    public void stop() {
      // nothing to do
    }
  }
  

Running this Application with all the bundles we create above plus the core OSGi-Bundles needed like (equinox.ds) will bring up the same application we’ve had after the first step. With the difference that now executing the search will really do something. We now have a running OSGi-Application which allows us to query Flickr for Photos.

• Last step is to integrate the “Flickr-Application” as a view in the existing Photo-Demo. This is done using an the ‘org.eclipse.e4.workbench.model’ extension point which allows us to contribute ModelElements to the e4 Workbench-Model.
  
  Pointing to an XMI-File like this.
  
• Add the bundles beside the one of the mock-Application to the Launch-Config of the e4-Photo-Demo and you now have support for searching Fotos from Flickr like shown at the start of the post.

I think one of the strengths of e4 is that it makes it easy to develop code in a way that you can run it standalone while developing. You can do this also to some extend in 3.x but at the moment you reach out to workbench-services you’ll get into trouble.

Writing a general mock framework for 3.x is quite hard because you need to rebuild the complete Workbench-Structure because your component is reaching out to them. For e4 the only thing needed is to provide mock implementation of the 20 things (=core workbench-services) and you are ready to work without bringing up an eclipse-instance to test your contribution.

This was orginally a reply on Elias post on e5:

On “should take risks”:
We agreed that e4 would be compatible with 3.x. Is not 100% correct: We agreed on the fact that e4 will provide a compat layer so that people can run the 3.x plug-ins which is a completely different thing IMHO because the underpinning designs of e4 are not influenced by this fact.

So what you suggest is what we’ve done in e4 we started with a new set of ideas and code leaving the old one behind already which you notice if you look at the plain e4-bundles in CVS.

On “needs a driver”:
The driver for e4 in my way of thinking is RCP and though you probably don’t believe we are on a good way to make development of RCP much easier. Yet what is missing is tooling, wizards and documentation and people who mastered to learn programming e4-Applications and give you a lending hand.

There’s no need anymore for using plugin.xml for example. You can create an e4 application in a fully programmatic way only you don’t know it as a newcomer.

On “must be easy to learn & master”:
I agree but we should not forget what we are talking about. This are not HelloWorld-programs nor a simple webpages. We are talking about business applications. Still this is a valid point and we need to do our best to give people convenience tools and API to hide away the natural complexities of a multi purpose platform like e4 is one.

General sum up:
I really don’t think that you need an e5 any time soon if you look at how modular e4 is designed from scratch with

• its extensible workbench-model at the bottom (it even allows you to add your own workbench concepts if you are unhappy with the one coming with e4)
• its plugable rendering structure on the top
• its abandoning of singletons making it useable in multi-user environments like RAP (by the use of DI)
• its leveraging of OSGi (Direct support for OSGi-Services through DI, usage of the OSGi-EventSystem)
• its even looser coupeling by the use of DI (e.g. I have code I run as plain SWT-Application and inside e4-Applications)

and this all with a really really small amount of size (as Boris already explained in his former reply your numbers are incorrect). The killer feature of e4 is that it comes with concepts and strategies to write UI applications but doesn’t force you the way to do it in certain way by allowing you to exchange (most) of them:

• You don’t like plugin.xml to make up your UI – Great don’t use it and make up the workbench model from code, your own DSL (e.g. there’s an Xtext-Tutorial at EclipseCon where they show of how to define an Workbench-Model using a DSL), …
• You don’t like the limitation of SWT or some of their controls – Great don’t use them and replace them with your own ones (and this even by not controling the Application-Startup like you had to do in your Ribbon-Examples for 3.x) by writing your own IPresentation engine which has about 5 methods you need to implement
• You don’t even like SWT at all – Great don’t use it, use Swing, Qt, ncurses and write your own renderers
• You don’t like DI but prefer to reach out to the OSGi-Service-Registry your own – Great do it. The argument that you don’t know which services are available is a tooling and documentation issue. The argument that you don’t know which services are available at a given time is something you need to get used to in dynamic environments like OSGi but at least e4 (when using DI) saves from writing code to handle this

I think e4 with the right documentation gives you (and many many people out there) exactly what you/they want so before starting to think about e5 I hope you dive deeper and exploit its possibilities.

To end this post what I like most about e4 is: It gives me back control of almost everything – if I want to – and I can’t live without this power (anymore).