Improvements to API Tools, Top Eclipse Helios Feature #8

I’ve been thinking a lot lately about what defines an Eclipse project? Not in the literal sense (a project hosted at eclipse.org that follows the EDP), but rather, what technical qualities do all Eclipse projects share.

Years ago the answer was simple, extensible IDEs. More recently Eclipse was defined as a tooling platform (for everything and nothing in particular), but when you start to look at where Eclipse projects are being used (Eclipse RT and modelling projects in particular), you realize that ‘a tooling platform’ doesn’t begin cover the spectrum.

Even eclipse.org has got out of the business of defining Eclipse. And while defining ‘Eclipse’ might not even be possible, there are a few technical qualities that all Eclipse projects share:

1. OSGi Based (most projects produce OSGi bundles) 2. A strong commitment to API 3. Meaningful versions

It’s the last two points that I want to focus on here.

Most Eclipse projects defined their versions based on API. We don’t use version sequences like 3.0, 3.1, 95, 2000, XP, 7. Instead, Eclipse projects define their versions such that a change in a version number indicates API compatibility (or incompatibility). There was an excellent tutorial at EclipseCon on this topic, and I believe that the connection between API and versioning is so important that it should be part of the undergraduate curriculum for software engineering.   Like many software engineering activities, manging the relationship between your API and version number is challenging, but it can be aided through tool support. Lucky for us there is an entire Eclipse component dedicated to API tooling.

As we approach the Helios release, I’ve been counting down the Top 10 Features I’m most excited about. Number 8 on my list is Improved API tooling support.

API tooling has been included in Eclipse for a number of years now. When you enable API tooling as consumer of API, you can identify when you are using methods you shouldn’t be:

Producers of APIs can use the tooling to help identify when they have ‘broken’ API:

While these features have been around for a number of years now, there are some noteworthy additions to API tooling. There is now a launch configuration which can be used to track API usage and generate HTML reports. This allows producers (and consumers) to see who is accessing non-API packages / classes / methods:

While this is valuable information, most most exciting advancements of API tooling is the new Migration Report. Using the migration reports we can determine if our bundle(s) can be (easily) migrated to a new version. For example, if the API producer decided to change the signature of their apiMethod to include a new parameter (and they properly released version 2.0 of their bundle), we could run the migration report and as a consumer.  Doing so would uncover any migration issues. In particular, on Line 10 in the doSomething method, we invoke a method that no longer exists.

More information on the migration tasks can be found on the Eclipse help system.  Thanks to Chris Aniszczyk, Michael Rennie, Darin Wright and Olivier Thomann for this work.

Note:  If I missed someone in the kudos, please let me know. I do my best to track down who worked on each feature :-).