Api Tools is Official

With much joy, I am happy to say that the Api Tools incubator project is now part of the SDK proper. We (Darin, Olivier and myself) have been working very hard to get it up and running (and useful).

The project has come a long way since my last post....

We now have:
1. an incremental builder
2. problem markers for api usage problems / api breaking changes



3. filters for api problem kinds



4. quick-fixes for a variety of api problem kinds





5. a wizard to set up api tooling on plugin projects



6. preference / property pages to configure options for the tooling



7. version management



8. @since tag management



Stay tuned for more updates...

Creating help just got a little bit easier

Are you looking forward to the 3.4 doc pass? No? Really now, where is your user assistance spirit?

In 3.4 PDE is hoping to improve your documenting days, specifically by making it easier to create, edit and review context sensitive help. The first step was to create a fancy new editor...


The editor allows you to quickly create and edit new new contexts, topics and commands. But the addition of dragging and dropping, cutting and pasting, opening linked files in various views, and more, is what makes this editor so much better then trudging through the xml. The editor should be the default editor for context help xml starting with today's I build.

There's more to come as well. During 3.4 PDE will hopefully be adding more features to help connect the context ids in your code with those in the xml.

A big thanks goes out to Chris and the PDE team, who managed to review and commit my 5000+ line patch in record time.

API Tooling is a work in progress

Lately I have had the chance to work on a new project a little outside the scope of debuggers: API tooling support for the platform. Ultimately the goal of this incubator project is to provide tools for 'working' with APIs. Working in this context is loosely defined as:

1. Manging API usage across builds/products
2. Creating API profiles to compare against
3. Tools to compare APIs
4. Tools to manage API breakage detection/repair
...

Alot more information can be found on the wiki for the project (here).

One of the features currently available in the project is the ability to manage API profiles. API profiles are considered to be a description of the API of a component (which can be a project, plugin, bundle, etc). These profiles can be used to compare current source to, or another component.

The following screenshot is the 'API Profiles' preference page used manage API profiles (hence its name :) )



Another feature is the ability to use Javadoc source tags to define API restrictions. The tags are provided as completion proposals for classes, interfaces, methods and fields. For example you could add a @noimplement tag to an API interface that clients are intended to use but not implement.

The following screen cap is a shot of a Java editor showing a variety of source tags.



These are of course previews of current ongoing work, so it could change at any time :)

One year of contributing

It has been exactly one year since I started working at IBM and one year since I started contributing to Eclipse.

To celebrate, I am spending the whole day testing!

... I suppose I could have tried to find something more fun to do. Maybe next week on my birthday (which happens to be Eclipse's birthday as well), I'll imbibe some kind of frosty beverage.