Beyond Code

What's Wrong with the Eclipse Plugin Infrastructure?

In theory, the plugin-architecture of the eclipse IDE is one of its strongest features, allowing it to leverage the effort of the entire user and developer base to improve and extend the basic framework in an infinite number of ways. The large number of contributed plugins (415 listed on the central plugin repository www.eclipse-plugins.info at the last count and counting) is proof of the excitement that eclipse plugins have generated.

However, my personal experience with eclipse plugins has been one big disappointment. I have found plugins a hassle to install, a pain to maintain, and frustrating and unrewarding to use.

While some of my frustrations have been due to problems of individual plugins, I believe that a constant source of irritation actually lies in the overall design of the eclipse plugin infrastructure.

Installation

There are two ways to install a plugin into eclipse: use the Install/Update feature from within eclipse (this requires the download site to support this - few do, and not all that do, do it well) or download a zip file and unpack it into the plugins and features directories in your local eclipse installation.

I am sorry to say so, but this is completely broken, in theory as well as in practice.

Theory

1. The plugin directory lives underneath the eclipse installation directory. If I reinstall eclipse (and given the speed of eclipse development, I do this every few months) I loose all my locally installed plugins. Furthermore, since there is no distinction between system plugins and local additions, it is not easily possible to tell the local additions from the core plugins, and so copy only them over to the new installation. (I can't just copy everything, since then I would be overwriting some of the eclipse 'core' plugins with their old versions as well.) To be fair, this situation can be improved on a bit through the use of sym-links.

2. The eclipse installation may be for the entire system, and not just reside in an individual user's home directory. Since the plugin-directory lives inside the eclipse installation directory, users require write-access to this directory if they want to add plugins. There should be a way for users to add plugins to their individual "profile" without requiring access to system directories.
3. Speaking of individual plugin "profiles", there should be a way for users to select which plugins they wish to see. Not all plugins play well with each other, and it should be possible for an individual user to "unsubscribe" from installed plugins which are not required by this user.
4. Why do plugin files have to be unzipped before installation? This causes no end of grief in practice (cf. below), but it strikes me as entirely superfluous in the first place. What happened to the concept of a JAR-file, which is distributed and installed entirely in one piece?
5. Speaking of JAR-files, what happened to the CLASSPATH concept? Why do plugins need to reside physically in a specific, fixed location on disk? I want to be able to give eclipse a list of arbitrary directories or files to search for plugins.
6. Why is there a features directory, separate from the plugins directory? What is the difference? Why should I care?
7. Why can't plugins be loaded and unloaded from within eclipse as required? The current system requires plugins to be available at start-up time. I realize that there may be very good technical reasons for this, but from a user's point of view, this makes no sense whatsoever.

Practice

8. Since plugins need to be unpacked before being installed, there is no way for the system to enforce a consistent package structure - instead, this task is (in practice) left to the unsuspecting user. I have encountered at least three different way that plugins are packaged: as plugins/org.downloadsite.plugin/<files>, as org.downloadsite.plugin/<files>, and as plain <files>. It is the users job to unpack the plugin in a safe place, fix its directory structure, and then copy the result into the plugins (and possibly features) directory underneath the eclipse installation.
9. The official naming convention for plugins is to have its top level directory be named according to its download site. Not all plugins adhere to this, making the already messy plugins directory messier still.

Troubleshooting

Once a new plugin has been installed, all is not well yet. Now the big question becomes: Does it work? Or rather: How can I even find out?

10. There is no obvious way to know whether eclipse has properly picked up a newly installed plugin. The best bet is Help -> About Eclipse Platform -> Plugin Details, which lists all (?) plugins found. However, this still does not tell me whether the plugin is operational or not, or what the plugin's expected behaviour is. It would be helpful if plugins were required to provide a "Happy Page", accessible from a standard location (such as the Plugin Details list above) and which at a minimum gives the results of a plugin self-test and maybe a few "Getting Started" pointers.
11. Once we know that eclipse has picked up a new plugin, we still have no way of knowing what it does and where to find it. Searching in Window -> Preferences, Window -> Open Perspective -> Other..., and Window -> Show View -> Other... will often reveal new entries, but not always. For instance, the teaminabox-metrics plugin adds an entry to the Properties item of the context-sensitive menu, which is obtained by right-clicking a project in the Java perspective (!). To their credit, this is clearly mentioned on their download page, but shouldn't there be a standard place for me to find this information from within my local environment?
12. Even if we find a new entry, we still don't know which plugin it refers to! For instance, both the teaminabox metrics plugin, as well as the Metrics plugin on SourceForge add an entry called "Metrics" to the project properties dialog: there is no way of knowing which is which.
13. Finally, there are those plugins which for all appearances are either not being picked up by eclipse at all, or which, despite seemingly being picked up, simply don't work. It is very hard to trace these problems - there is no way to "force load" a plugin, and the log (hidden in ~/workspace/.metadata/.log - note the clever cascade of invisible files!) usually does not show anything helpful. A highly visible log-file in a standard location with verbose messages would be a great benefit for an application undergoing such rapid development as eclipse (and its plugins!) are today.

Release Management and Individual Plugin Problems

The large number of contributed plugins listed on www.eclipse-plugins.info is a bit misleading. While there are definitely some outstanding contributions, careful inspection reveals that only a relatively small fraction of the non-commercial plugins are both usable and useful. Many of the non-commercial offerings are either "experimental", or relatively trivial applications, written primarily (one suspects) as a fingering exercise by the respective author - a perfectly good reason to write a plugin, of course, but not necessarily a good enough reason to release it to the world.

For users to benefit from eclipse's plugin architecture, it is necessary that users can find the plugins they need to solve their problems. Having a central repository for plugins is great. But if the only way for me to distinguish between a mature and an experimental plugin is to download and install them both, the entire plugin concept starts to looks much less of a good idea to me. Even more so, given all the problems with the actual installation process detailed above.

A distinguishing feature of large successful open source projects is the existence of a process by which the quality of contributions can be controlled, either through a "benevolent dictator" or a through a more community-oriented voting process. The Apache Jakarta project, for instance, has been very good at this: for anything available on the Jakarta website, I can be pretty sure that it does something useful, does it reasonably well, and is sufficiently finished to be usable by others. It is this service of QA, which makes Jakarta so much more powerful compared to other projects.

Dare I suggest that, for plugins to realize their potential, eclipse will require some form of selection process? There are a number of ways a steering body might help improve the overall quality and usefulness of plugins (and, by implication, of the eclipse platform): For instance by distinguishing more clearly between "experimental" and "released" plugins, by enforcing adherence to packaging and naming conventions, by requiring a certain level of quality and documentation. Note that the current plugin repository website, through its semi-official nature already provides some selection functionality. Maybe some form of steering body should start to take a more active role.

Closing

This is where the conclusion should be, but I am afraid I have nothing to add. For the most part, the eclipse project seems to be going well - I hope it will continue to do so.