Eclipse Ganymede: An in-depth look at PDE (Plugin Development Environment)

As part of the upcoming Eclipse Ganymede release which is scheduled for June 25th, InfoQ will cover a series of Eclipse subprojects. Today, the subproject is PDE (Plugin Development Environment), which is releasing version 3.4. InfoQ spoke with Chris Aniszczyk, PDE Technical Lead and Principal Consultant at Code9, to learn more about PDE and what it provides.

Aniszczyk described several new features and updates in 3.4, including:

• API Tooling - API tooling provides a builder that reports API usage and binary compatibility errors in the workspace. You must configure projects that you want API tooling to report errors on and you must define an API baseline to compare against workspace projects. For example, for the Eclipse 3.4 release, the Platform team used API Tools to define a baseline on Eclipse 3.3.2 when we were developing against 3.4. API Tools was able to report compatibility errors, missing @since tags, incorrect version numbers and many other API issues that we normally had to do check manually for. Now all this cool stuff happens within your workbench so you can see errors while you're developing. Oh, you added a method to an interface but forgot to rev the version number, API tools can help you with a nice quickfix! Check out the API Tooling wiki for more information
• Open Plug-in Artifact - If you use Eclipse you most likely have used the JDT's awesome Open Type shortcut (Ctrl+Shift+T). Well, we finally have something similar in PDE. Open Plug-in Artifact (Ctrl+Shift+A) allows you to quickly just jump to plug-ins, extensions, extension points and exported packages. Give it a try, I'm sure you'll like it! I use it everyday now!
• User Assistance Tooling - For those who love providing user assistance in their Eclipse applications, they will be glad to hear that PDE provides a new Table of Contents editor and Help Context Editor. Instead of editing these files by hand, you will now have the option to use a nice editor. On top of that, we also improved the Cheat Sheet editor for 3.4!
• Plug-in Spy - [This] was born out of my own personal frustration in just trying to find functionality in the SDK to reuse and also finding specific selection classes. For example, imagine you're working on an RCP project and you want to re-use the log view within your application? In the past, you had to dig through code and extensions to find IDs and other things. The Plug-in Spy allows you to circumvent this by simply selecting what you're interested in the workbench and getting useful information about it. For example, in this case you would select the log view and invoke the Plug-in Spy. The information you would get back is things like the actual class that implements the view you're looking at, which plug-in the class comes from, the current selection class, etc.
• Plug-in Registry - [This] view in PDE allows you to quickly see the state of your current running application. For example, you'll see the plug-ins that are currently active and running, versus the ones that aren't. You can also quickly see and query the available extension and extension points for these plug-ins too. In 3.4, we also added a concept of 'Show Advanced Operations' on this view. This allows you to start, stop and diagnose bundles all conviently from a view instead of doing it via some other means. If you're in need of a view to quickly see the state of your Eclipse-based application, this view is for you!

When asked about using PDE to develop other things besides Eclipse plugins, Aniszczyk said:

For the last few releases, PDE has provided support for developing OSGi standalone applications. However, we have done a bad job of advertising this. It's a bit hidden in the 'New Plug-in Project' wizard, but we allow you to target a specfic Eclipse version or a OSGi framework. I think part of the problem is that we have this naming issue, right? In Eclipse, we are used to the word plug-in and in the OSGi community they are used to the word bundle. In certain areas of PDE, we try to accomodate this wording, but we aren't there yet. For example, if you create a Plug-in Project and target an OSGi environment, you'll notice that the OSGi Framework launch configuration uses the term 'bundles' instead of 'plug-ins.' Oh, the OSGi community may be interested to know that PDE plans to provide tooling for Declarative Services in 3.5... we have some exciting work going on currently in the PDE incubator.

Aniszczyk also went into further detail about developing OSGi applications with PDE, saying that the same mechanism that is used to target an Eclipse version can also be used to target an OSGi framework, and that templates are provided for standalone OSGi applications in addition to different Eclipse versions. Aniszczyk pointed out the PDE eases OSGi development by managing the classpath and by leveraging the existing Eclipse development toolset. PDE provides Equinox support out of the box, and also provides extension points for other OSGi frameworks such as Knopflerfish and Felix. Aniszczyk also expressed a desire to work with the developers of the various OSGi frameworks to integrate tiehr offerings into PDE, and said that the PDE team is always willing to help those who want to contribute.

Aniszczyk also discussed the PDE community, in particular around the BugDay effort which he helped to kick-start. There have been over 100 contributed BugDay bug fixes for PDE, and Aniszczyk expressed amazement at what could be accomplished with only a little bit of help from the PDE team via IRC. Aniszczyk also said that the best way for a member of the community to help out with PDE was to look through the list of BugDay bugs in Bugzilla and to express interest in helping -- from there, the PDE team will be more than happy to offer assistance via IRC or Skype, which corresponds with the PDE motto, "we do tooling, but our business is people".

When asked how PDE would be integrated into or affected by e4, Aniszczyk said:

PDE is definitely invovled in the E4 effort. The current focus on E4 is to help build a platform but as we all know, platforms eventually need tooling. Here are a couple directions we're exploring in the E4 currently:

• Multi-Lingual Plug-ins - Currently, all plug-ins are written in Java. In E4, there is a focus at looking at other languages like JavaScript and looking at the web as a target environment. It has always been a dream of mine to write Eclipse plug-ins in other languages like JavaScript, Groovy or Scala. In order for this to happen, PDE will start becoming more of a platform for people. There are currently not enough hooks available in PDE to make multi-lingual plug-ins happen and also there has to be runtime support
• Single Sourcing and Target Platforms - If you use Eclipse and develop plug-ins, you're probably familiar with the notion of a target platform. In PDE, the target platform simply represents the set of plug-ins your developing against. For example, by default, you develop against what you're currently running. In E4, there is a push to target various environments like the web, device and who knows what else. To get an idea of what I mean, check out the Eclipse EBERT example which demonstrates an Eclipse-based application that runs on the client, server, and embedded devices using Eclipse Rich Client Platform (RCP), Eclipse Rich Ajax Platform (RAP), and embedded Rich Client Platform (eRCP) respectively. The process to develop these type of applications is a bit difficult since in PDE, the concept of the target platform is per workspace. So for each platform you're targetting, you need to switch your target platform to those set of plug-ins. In E4, PDE will aim to support setting targets on a per project level, similar to the way you can target a JRE on a per project level
• Provisioning (p2) - Now that Eclipse has a completely revamped way to update plug-ins, p2, there's a lot of opportunity to create some fantastic tooling. In 3.4, the PDE team worked hard to update the existing tooling around the old update system to make it p2 aware. The next step for e4 (and even 3.5) will be to make the tooling not only p2 aware, but integrate well with the p2 system so we could do things that were not possible before. For example, imagine a world where you could do push-button publishing instead of the current way of generating update sites. Also, imagine the ability to simply right click a plug-in and have it deployed to where you want it... maybe a self-hosted workbench... maybe a current running application. Expect to see good things in the area of p2 tooling in e4 and even in 3.5

In the end, there will be a lot of exciting work that is going in E4 and PDE will be heavily involved. I always say, you can build really cool things but without solid tooling, adoption will suffer.