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.

I had a colleague of mine who recently started a consulting gig doing some Eclipse work locally and he’s running into the problem of teaching his client Eclipse plug-in development workflows. But before we get into that, he managed to find one of the few clever easter eggs we have hidden throughout PDE:

He was highly suspicious of PDE giving him code completion for my name but I told him it’s reasonable, my last name is pretty hard to spell 🙂

So, back to answering his question on plug-in development workflow. When the PDE team gives a tutorial about plug-in development, we generally include this graphic detailing how we think the workflow should be:

The graphic may not be that useful for experienced Eclipse developers, but we’ve found it helps new people understand the basics of plug-in development. Early next year, I plan to write an article that goes over these steps in detail and the tooling we provide for these steps (e.g., the Organize Manifests wizard).

Ok, back to my special egg nog mix. Happy Holidays!

In the spirit of making it a plug-in developers’ Christmas, the PDE team is bringing you some new functionality. There’s one thing I’ve always loved about Eclipse, and that is the Open Type dialog (Ctrl+Shift+T). I’ve always wanted to have something similar in PDE and the good news is now we will. I spent the last few days in the PDE Workshop and this is what I came up with:

Look for it in Eclipse 3.4M4 once I can come up with a good keybinding 🙂

In Eclipse 3.4, source will be shipped as individual bundles instead of the old way via the org.eclipse.pde.core.source extension point. So now you will see many bundles with the format of <id>.source floating in your Eclipse installation. What’s nice about this is that now source is just shipped as another corresponding bundle so there’s more flexibility there. If you peer inside these bundles, you’ll discover a new manifest header:

Eclipse-SourceBundle: org.eclipse.pde.core;version="3.4.0";roots:="ant_tasks/pde-antsrc,."

This header simply states what bundle you’re providing source for (ie., org.eclipse.pde.core) and where the source roots are within the bundle.

If you need more information, check out this wiki entry.

This new source format will make its debut in Eclipse 3.4M4.

During the past couple weeks, I ran across a few people and bugs that dealt with externalizing strings in PDE. For just about every issue that I came across, the problem could’ve been easily averted with some best practices around plug-in development.

The first best practice is to always remember to use the Externalize Strings wizard in PDE:

Let PDE and the wizard do the work for you:

The second best practice is to enable compiler settings around externalized strings for plug-in development (these are set to IGNORE by default):

When this compiler setting is enabled, you will get warnings around strings that need to be externalized or can’t be found in a properties file based on your Bundle-Localization MANIFEST.MF header.

With these plug-in development best practices, you should have no problems externalizing strings the proper way for your plug-in based applications.

Hope this helps.

About once a year, I’m graced with a message from PDE complaining about plug-ins being out of sync. It’s a nasty message as it usually catches you by surprise and makes you wonder how the heck can anything be out of sync?

Some lucky Eclipse community members have run into this issue also… which is unfortunate because it’s generally not an easy issue to fix without understanding what is going on behind the scenes. From a PDE viewpoint, the error message simply indicates that one of the bundles within the PDE state has been somehow modified outside the workspace.

I can cause this error to appear when opening a MANIFEST.MF outside of Eclipse in VIM and editing it. I believe this is what most people do for that error to appear. In any case, enough talk and back to the point of this post, what to do when !@#$ hits the fan in PDE. Here’s what to do if you’re convinced that PDE is being bad:

1. Restart Eclipse. If the errors don’t go away…
2. Start Eclipse with the obscure -Dpde.nocache=true property. This should force a rebuild of the PDE state. If the errors don’t go away…
3. PDE stores its state in the workspace (metadata/.plugins/org.eclipse.pde.core), delete it the old-fashioned way.

If everything fails still, I’m pretty sure PDE isn’t at fault anymore and it’s something else.

I hope this helps.