Today, I set out to create an Eclipse update site to host Team 449’s plug-ins. (If you’re in a rush for answers, just scroll to the bottom.)

Eclipse is actually one of the less buggy of applications. It doesn’t crash every three minutes like Bloodshed Dev-C++, it doesn’t crash every two minutes like Internet Explorer, and it doesn’t crash every minute like Windows. The Java development environment is beautiful, the task management system is well-designed if poorly-integrated, and the C++ development environment is second only to Emacs, Vim, Ed, and the ever-elusive butterfly technique (its not actually that great). Eclipse has a unique system of managing views and perspectives that allows a huge amount of flexibility to the user. But Eclipse’s plug-in development environment is less than satisfactory to the developer.

To begin with, Eclipse plug-ins are based on a less-than-easy-to-use API. Sure, its easy to do the things the designers anticipated you would be doing – like compiling their sample projects. But there’s no level of abstraction between “here’s a method to do exactly what you want” and rewriting half the API from scratch. Furthermore, the Eclipse developers insisted on creating their own system for everything, from user interface functionality to file system access. A good deal of the documentation is totally obscure, and the sample projects are no help.

Now suppose you’ve suffered through the experience of writing a plug-in, you’re almost done, and you’re ready to export. Or more likely, you’ve just begun, and you’re ready to export just to see what happens. There’s just one little problem – that tiny icon over in the “package explorer” with the red X or the yellow exclamation point – Eclipse doesn’t like something. Such was my situation as I was trying to export my plugin, so that I could export my feature, so that I could test my update site.

Tags: Eclipse, HTML, Java, Javascript, Plugin, Programming