Chris Aniszczyk's (zx) diatribe

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.

When working on Eclipse, you get spoiled as a developer with certain things. I for one, get spoiled silly with the wonderful Java development environment provided by the JDT.

However, another thing I get spoiled by is plug-in versioning. Eclipse actually has versioning guidelines that are reasonable and pretty well followed within the Eclipse Platform. It’s not like where in certain experiences, I’ve known people to make up versioning guidelines without any respect to API and just rev the version when you release, whether things have changed or not. In essence, plug-in versioning is something I believe should be taken seriously and well thought about it before slapping something on (or just leaving the version empty like most people do).

To help with plug-in versioning, I recently dropped code in the next I-build based on an old bug that I had time to hack while on the long plane ride. Here’s the use case…

You’re trying to version a plug-in and open up the properties dialog:

That’s not too helpful… sure you can specify the versions but you aren’t really sure what you’re developing against. Here’s how it looks like after the patch:

Now you can see the versions available in your target and workspace. If you select the ones you’re interested and click match, it will properly construct the minimum and maximum versions:

So, let me know what you think. Also, this means no more excuses when setting up your dependencies and versioning plug-ins, OK :)?