EclipseCon 2012

This year's EclipseCon was especially exciting because my colleague Fredrik and I had a talk accepted and was one of a few highlighted sessions.

Our talk was about sharing our experiences of migrating one of FindOut's tools to the new Rich Client Platform "RCP 2.0" in Eclipse 4.2:

Here are the highlights from the conference:

Monday:

The conference started out with an excellent tutorial on writing rich client applications with Eclipse RCP 4.x by Kai Toedter. He also showed that the default SWT rendering engine in the platform can be replaced with Swing. He used the Napkin theme for his contacts demo. Very impressive!

Tuesday:

Tom Schindl explained the new application platform and showed how to easily pool resources and a locale support service that he connected to google translate. The audience was asked for a language to translate to, and without restarting the application "Hello World" was switched to "Hallo Verden" (Norwegian). Impressive!

Brian de Alwis showed how to style your 4.x application with CSS. He also demoed the nifty CSS Spy and editors. For us who had little knowledge of CSS this tool came in real handy.

Alexander Nyßen gave a comprehensive overview and history of GEF. He also explained GEF4 and the main priorities to introduce there. We were especially glad that one of the bullets was to migrate GEF to use the new 4.x application platform.

Wednesday:

Figuring out the compat layer

Tom Schindl talked about e(fx)clipse which is a distribution of Eclipse for creating JavaFX applications. He also showed that the default SWT rendering engine in can be replaced with JavaFX.

After lunch it was time for us to present.  We were happy to see that we had about 60-70 attendees in the room. The presentation and demo went very well and we had a very good discussion with the audience during the Q/A.

In the evening we attended the e4 BOF which was well attended with all the key people from development and a number of users. One interesting topic was how the solve the problem of having multiple dependency injection frameworks. One example is that Xtext uses Guice. It was also noted that 4.2 is lacking a documented API, something that will be addressed in 4.3. Many of the common UI components such as the Properties view, the Project Explorer and the Preference dialog need to be migrated to the new platform services.

Thursday:

Eclipse 4 meets CDO - inspiring demo of what you can do with the modeled application. Since the application model is implemented using EMF, CDO can be used to share it between multiple users. Think instant content sharing and collaboration using the application model.

In the closing session it was revealed that the conference had 650 attendees with 360 of them first-timers. 36 countries and 41 US states were represented. There were 2972 complaints on the WiFi according to Mike Milinkovic. All of this was washed down with almost 7000 beers.

One valuable thing for us was meeting and mingling with everyone including other swedes from companies such as Ericsson, Sandvik, IAR and Oracle...

It was also great to meet the e4 team face to face. We would especially like to thank Remy Suen for fixing a bug that we ran into when migrating our application.

Finally, a special thanks to the Eclipse Foundation for yet another great Eclipse conference!

References

1. We've made some example code available on github.
2. Bug 374597 - [Compatibility] ClassCastException when adding pure 4.x view to 3.x perspective running in compatibility mode

Visualizing Eclipse Project Dependencies with Zest

I wonder how many Java developers that are using Eclipse to develop systems the old-fashioned way without using OSGi? It feels awkward and strange not to use OSGi if you are used doing that, but sometimes you don't have a choice when working with legacy systems.


It is well known that when the system grows it gets harder to maintain a clear separation between different parts of the system. Dividing the system into Eclipse projects does not help much since the tool lacks functionality for managing project dependencies. When developing applications using plug-ins and OSGi I have used the PDE Dependency Visualization tool. However, it only works for plug-in projects and does not show project dependencies for standard Java projects.

Googling for an existing solution didn't help much. The only discussion about this was a suggestion to parse all .classpath files and build a DOT file for GraphViz to display. Oh well, I did some hacking for a while, forgetting everything I read in the Clean Code book. The result was a standalone Java program that generated the needed DOT file. It was working ok and the GraphViz tooling could create the graph as an image for me. What I really wanted, though, was to have a view in Eclipse that showed my dependencies just as the PDE Dependency tool does.

The PDE Dependency tool is using Zest: The Eclipse Visualization Toolkit, so I decided to take a look at it. To my surprise it turned out to have exactly what I needed, namely Zest Viewers modeled after JFace.

With that I could create what I needed with just these few steps:

1. Install the Graphical Editing Framework Zest Visualization Toolkit SDK in Eclipse.

2. Create a Plug-In Project using the "Plug-in with a view" template. Change the default names to be more suited, for example the view class name to "ProjectDependencies".

3. Add the following plug-in dependencies:

• org.eclipse.zest.core
• org.eclipse.zest.layouts
• org.eclipse.core.resources

4. In the view class, ProjectDependencies.java, change the TableViewer to a GraphViewer and use the following code in createPartControl :

public void createPartControl(Composite parent) {
  viewer = new GraphViewer(parent, SWT.NONE);
  viewer.setContentProvider(new ViewContentProvider());
  viewer.setLabelProvider(new ViewLabelProvider());
  viewer.setLayoutAlgorithm(new TreeLayoutAlgorithm(LayoutStyles.NO_LAYOUT_NODE_RESIZING));
  viewer.setConnectionStyle(ZestStyles.CONNECTIONS_DIRECTED | ZestStyles.CONNECTIONS_DASH);
  viewer.setInput(null);

5. Change the content provider to implement the IGraphEntityContentProvider interface. Since the Resources plug-in already has the model of all Eclipse projects and its dependencies I can easily use it to return what is needed for implementing the content provider:

class ViewContentProvider implements IGraphEntityContentProvider {
  public Object[] getElements(Object parent) {
    // Return all projects in the workspace
    return ResourcesPlugin.getWorkspace().getRoot().getProjects();
  }

  public Object[] getConnectedTo(Object entity) {
    IProject project = (IProject) entity;
    try {
      // Return the project dependencies
      return project.getReferencedProjects();
    } catch (CoreException e) { }
    return null;
  }

  public void dispose() { }
  public void inputChanged(Viewer viewer, Object oldInput, Object newInput) { }
}

6.The last step is to change the ViewLabelProvider to return the project name.

class ViewLabelProvider extends LabelProvider {
  public String getText(Object element) {
    if (!(element instanceof IProject))
      return null;

    IProject project = (IProject) element;
    return project.getName();
  }

  public Image getImage(Object obj) {
    return null;
  }
}

Running the plug-in project as an Eclipse application and showing the view shows the project dependency graph:

Zest contains a lot more that could be utilized, such as a number of different layout algorithms, but this simple solution was exactly what I needed. I was surprised to see how easily I could achieve it, once I found the right component to reuse. Reusing existing software feels great, and the Eclipse platform has a lot of it!