Eclipse e4 has sometimes the tendency to do thing differently then expected. For example the modeled workbench may not show certain UI elements. In this case it is difficult to find out what is wrong.
This blog post tries to help to look inside the initialization process of an Eclipse e4 application.
In my e4 tutorial I write that you always have to start the application “org.eclipse.e4.ui.workbench.swt.E4Application”.
The implementation class is “org.eclipse.e4.ui.workbench.swt.internal.E4Application” and can be found in the plugin “org.eclipse.e4.ui.workbench” in. This instance of IApplication is created by the framework.
In this class you find the main entry point to your application:
public Object start(IApplicationContext applicationContext)
throws Exception {
}
The following line creates the mighty IEclipseContext.
IEclipseContext appContext = createDefaultContext();
In createDefaultContext() you find for example that e4 sets initially an empty Styling engine and you find the registration of the extension registry.
The next line is more interesting, its load the models. Here you can check if the model entries are available as expected.
MApplication appModel = loadApplicationModel(applicationContext,
appContext);
Just in case you are wondering “M” Elements refer to the UI workbench model modeled with EMF. MApplication is the model element for the application and extends for example MContent which allows to store the IEclipseContext.
After a few lines of compatibility stuff the the model is added to the IEclipseContext and vise versa:
// Set the app's context after adding itself
appContext.set(MApplication.class.getName(), appModel);
appModel.setContext(appContext);
The next lines are interesting as they also reveal typical errors (I make). They load the parameters for “applicationXMI”, css stylesheets and the rendering engine. Here you can check if you parameters are read by the engine.
// Parse out parameters from both the command line and/or the product
// definition (if any) and put them in the context
String xmiURI = getArgValue(E4Workbench.XMI_URI_ARG, applicationContext);
appContext.set(E4Workbench.XMI_URI_ARG, xmiURI);
String cssURI = getArgValue(E4Workbench.CSS_URI_ARG, applicationContext);
appContext.set(E4Workbench.CSS_URI_ARG, cssURI);
String cssResourcesURI = getArgValue(E4Workbench.CSS_RESOURCE_URI_ARG,
applicationContext);
appContext.set(E4Workbench.CSS_RESOURCE_URI_ARG, cssResourcesURI);
// This is a default arg, if missing we use the default rendering engine
String presentationURI = getArgValue(E4Workbench.PRESENTATION_URI_ARG,
applicationContext);
if (presentationURI == null) {
presentationURI = PartRenderingEngine.engineURI;
appContext.set(E4Workbench.PRESENTATION_URI_ARG, presentationURI);
}
The last lines are for actually creating the E4Workbench and running it.
/ Instantiate the Workbench (which is responsible for
// 'running' the UI (if any)...
E4Workbench workbench = new E4Workbench(appModel, appContext);
The class “org.eclipse.e4.workbench.ui.internal.E4Workbench” is worth a look. It defines the fixed values for the possible parameters, e.g. “applicationXMI”.
The init() method is responsible for creating the UI in the method call Workbench.processHierarchy(appElement); where appElement is initially the MApplication. processHierachy() is then recursively called for all model elemements.
I hope this helps in evaluating and debugging the e4 platform. Let me know what you think.
but at least I try. 
