Chris Aniszczyk's (zx) diatribe

As a reminder to everyone, the plug-in development webinar that Brian Bauman and I will be doing is coming up on January 22nd. If you’re interested in learning the basics of plug-in development along with some tips and tricks, please attend. If you have co-workers thinking about plug-ins or confused about what a plug-in is, have them attend! The layout of the webinar will be like this:

• The Basics
• Plug-in Architecture
• Plug-in Development with PDE
• Tips, Tricks and Best Practices
• Q&A

Sometimes it’s difficult to do these webinars because you aren’t sure who your audience is going to be or you have to find a picture of yourself as handsome as Mik’s:

Brian and I tried to divide the webinar into two parts. The first part should please the beginners and the second part should please all plug-in developers with some experience. In the end, everyone gets to ask questions 🙂

Because the PDE team loves suspense, we will have a mystery guest available to answer your questions in the chat:

To register for the webinar, send an email here.

I always like to chuckle about my past Eclipse programming experiences. I remember one of my earlier tasks involved showing the error log view for something. I thought that the workbench would be responsible for that somehow… and I was right!

PlatformUI.getWorkbench().findView(...)

However, to my dismay, the parameter was a magical identifier that I didn’t know. It took me awhile to wade through Eclipse source code to find the identifier. An by awhile, I mean more time than it should have taken. There are much better ways to find magical identifiers these days… here are two ways:

(1) Plug-in Registry View

The Plug-in Registry view allows you to quickly find information regarding plug-ins and extension points. If you’re just interested in extension points, I’d set a filter to show only extension content only:

After that, you’re presented with a list of extension content only. Let’s focus on org.eclipse.ui.views as that’s our extension point of interest here:

Next, let’s try to find that pesky log view identifier:

That wasn’t so bad now, was it :)?

(2) Plug-in Spy

In Eclipse 3.4, it will be even easier to find certain types of identifiers using the Plug-in Spy. You just have to look at what you want and press ALT+SHIFT+F1:

Ok, those are all the tips today from your friendly PDE developer 🙂

Ok, maybe API isn’t like a box of chocolates, but it’s something important, usually very hard to craft and even harder to maintain. However, I felt like I needed to use the tagline since I saw Forrest Gump recently.

API is also one of those things that I come to love and respect about Eclipse. In my personal opinion, the care the Eclipse teams takes in its API’s can be attributed to the success of Eclipse over time. For a person outside of Eclipse committership, it’s difficult to appreciate the diligence the Eclipse team takes in regards to APIs. On top of the time it takes to craft good APIs, it’s even more difficult to maintain them over time! There are all these silly little rules you have to follow to make sure you don’t break any clients.

Well, I’m happy to announce that the PDE team is attempting to graduate the API Tools project from the PDE Incubator for 3.4M5.

What is the API Tools project? Well, the goal of the project is to assist developers in API maintenance by reporting API issues such as binary incompatibilities, incorrect plug-in version numbers, missing or incorrect @since tags, and usage of non-API code between plug-ins. For those who don’t understand what this means, let me show you pictures.

The PDE API Tools let you work against API Profiles:

In this case, I setup my API “baseline” to be against the Eclipse 3.2.2 SDK. This means that all the code I’m developing should not break any APIs found in the 3.2.2 version of Eclipse. The next step would be to tweak some compiler settings in regards to see how I want errors reported:

Now that everything is setup, I was working on some PDE code and did something stupid… I modified the signature of an API method and forgot that would break my clients (ooops!) and cause many nasty bug reports to come in. Never fear, PDE API Tools is there to save my day:

Kind of cool, huh? It blows me away at least. It may not be perfect yet, but the API Tooling is a step in the right direction. Just imagine being told that you should increment your plug-in version because you modified your API in some shape or fashion. Wow!

In my mind, the beautiful modularity story Eclipse (OSGi) has combined with this type of tooling is solidifying Eclipse as an impressive runtime technology. When I have to step outside plug-in development sometimes to work with web technologies, I feel a bit like a luddite using punch cards.

There was a recent blog post about someone complaining (can’t find it atm but sounds like something Eugene would do ;p) that the PDE and JDT new project wizards were too complicated. After the PDE team’s feelings were crushed and the tears subsided, we simplified the wizard. This was done by moving the Execution Environment setting to the second page and removing the confusing Classpath (Bundle-Classpath) option:

If you have any other ideas to simplify things for users, please let the PDE team know by filing a bug.