PDE, Harmony and the Foosball Prodigy

An exciting pattern that has emerged in the past year is that the Eclipse PDE (Plug-in Development Environment) has found a following among non-plug-in developers.

At EclipseCon, Tim Ellison showed how the Apache Harmony project (a compatible, independent implementation of JSE 5.0) uses PDE as a "module development environment".

Harmony developers are not developing Eclipse plug-ins, but they want to tap into the cool tooling that is available to Eclipse plug-in developers .

The Harmony code base is split into modules. Each module is self-describing and uses an OSGi bundle manifest to define its API (via the Export-Package header) and describe its dependencies on other modules (via the Import-Package header).

The use of OSGi bundle manifests in the Harmony modules automatically qualifies these modules for free classpath and target management by PDE.

By using the PDE container to dynamically compute the classpath, .classpath files become sharable and the developer does not need to update his project's classpath ever again.

Access rules are used in the manifest file to enforce API discipline among modules. PDE translates these runtime visibility rules into compiler access rules at development time, resulting in compiler warnings/errors when an API violation occurs.

By setting the target platform to the location of the Harmony JRE, developers free themselves from having to import all modules into their workspace. All they need in their workspace is the subset of modules they are working on; the rest can be referenced on the file system transparently via the PDE container.

So if you want to modularize your code base, PDE can help.

On a related note...

Also working on the Harmony project is a young man named Oliver Deakin. A fine developer in his own right, Oli also happens to be a Foosball prodigy. Take a look at a short video of some of his trickshots. The video will knock your socks off, so please have an extra pair of socks handy :-)