Worst. Blog. Ever.

…this is one of them.

As Wayne Beaton reminds us, successful Open Source projects at Eclipse (or anywhere) require an active community, and that requires participation from the folks writing the code.  Working on the code that powers JSDT and WTP Source Editing is only part of being a Committer.  Of equal importance is interacting with users, fellow committers, and adopters.  But something’s been lurking in the back of my mind around all of this and I can’t quite see a solution.

A few months ago Konstantin sent a link to wtp-dev to a question on StackOverflow.  To those who’ve never used it, a gross oversimplification would be that it’s a programming Q&A site.  One of its creators, Jeff Atwood, is responsible for the well respected Coding Horror blog (which everyone really should read, but take with a grain of salt, even if the rate of posts has dramatically slowed since the launch of stackoverflow and co.).The post was a question about overall WTP performance, and although some progress on providing concrete answers was made, its existence gives me pause.  Not because the impression seemed to be that we don’t care about performance (we do), nor quality (we do), and that there were surely lots of people willing to step in (a retort from Zombieland‘s “Tallahassee” comes to mind), but the problem for me was that it wasn’t asked on our own forums.  There are lots of questions related to Eclipse on Stack overflow, and many of them have gone unanswered for a very long time.  My gut reaction is to simply answer as many as I can, but that’s not practical.  I’ve tried it, and answering older questions never seems to attract the questioner’s attention for followups or filing real bug reports.  Plus I already spend a fair amount of time in eclipse.org’s own forums and IRC trying to make sure WTP questions don’t go unanswered.

So how do you make progress in a situation where an active and vocal part of your community chooses to congregate somewhere other than the place you’ve carved out just for them, away from the folks who might best be able to answer their questions?

Honestly I don’t have an answer for that.  I don’t blame the forum software, after all Eclipse’s forums have always had a traditional NNTP service underneath them, and I’m a staunch advocate of continuing to do so as it lets me use whatever interface I’m most comfortable with.  StackOverflow’s an invaluable resource provided by some pretty smart folks, and I can’t really fault users for asking questions there.  And so here I am, a quarter to 4 in the morning, hoping that getting this out in some form will finally let me get some sleep. Somehow I doubt it.

I’ve seen more than one post applauding the enhanced use of content-type specific icons in Eclipse 3.4M6 and showing how to make use of them through an extension or org.eclipse.ui.editors, but I think that something needs to be pointed out about that solution. Developers who do this aren’t just specifying their icons, they’re specifying whole new editors. This isn’t a bad thing, but every editor has to have a unique ID, and it’s easy to forget that some other features depend on that editor ID. The most common example is the org.eclipse.ui.actionSetPartAssociations extension point, which adds menu and toolbar actions automatically as you switch from workbench part to workbench part. In WTP, this is how the JSP and Web Page Editors ensure that the Run menu is present and populated with the Launch action set, and it’s how most editors expose the Annotation Navigation action set. So when you’re registering an editor to get that custom icon showing up, keep in mind that there may be more to it than reusing the right editor and editor contributor class.

Many of the Eclipse projects are presented as Platforms, but to make a successful platform you have to balance at least two factors in much the same way as an economist: the value provided and cost incurred. The value added is simply the feature set–is there something of use in there? The other factor, cost, is made up in part by the requirements. For Eclipse plug-ins this is often only thought of as which plug-ins it requires to run, but there’s also the Execution Environment to consider.

One of the great things about the PDE is that when you specify an Execution Environment for plug-in projects and have matching Installed JREs within the preferences, it will automatically target your plug-in projects to use the right JRE. No more warnings about generics in a project that hasn’t adopted Java5 syntax or about not supporting them in the targeted JRE. This even lets you build plug-ins specific to each environment if needed, allowing for multiple implementations of the same functions, or more commonly the graceful deactivation of certain features when running in older environments.

The larger ramification is that the Execution Environment is now every bit as critical to think about as the plug-in and version dependencies. If you are developing a plug-in that specifies an Execution Environment of J2SE-1.4 but has a dependency on a plug-in specifying an Execution Environment of J2SE-1.5, your plug-in now implicitly has an Execution Environment of J2SE-1.5 as well. Conversely, the Execution Environment you specify on your plug-in has a direct effect on how readily it can be used by someone else, and that affects the cost of adopting your platform. It’s little surprise that much of the Eclipse Platform as we know it requires J2SE-1.4 or less. So keep in mind the Execution Environment you choose for your plug-ins–some day you might find it running in the most unexpected of places.