How the eclipse update manager could look like...

One of the features I don't like about eclipse is the update manager. A few weeks ago, I looked at different alternatives of eclipse update managers. Today Chris Aniszczyk blogged about the FireFox update manager. Interestingly, a few days ago, I created a small flash video on the FireFox update manager, because I think that shows what a user expects from a simple to use update manager.

One of the central paradigms of eclipse the idea of plugins. However from a user perspective, managing plugins is a nightmare. The eclipse update manager is way too complicated, too slow, not robust enough.

Few weeks ago I bought Eric Evans book "Domain Driven Design". I'll blog about it separately. One of the central ideas is what he calls "ubiquitous language" (e.g. read chapter one). The basic idea is to come up with a language to describe the problem domain, in our case the installation and update of plugins. The language is not only used in conversations but also represented by a formal model. The formal model is implemented in code. You can start reasoning and discuss about the model.

If I look at the eclipse update manager, the model used is a very technical model that is totally implementation centric. It is not a model a user of the update manager can simply understand. I think this is the root of the problem. We have to come up with an update manager domain model that represents the problems and tasks a user of eclipse faces and not a model that is focused on the implementation. The current implementation could be used to implement the user model, but in it self it seem not the right abstraction for users.

The FireFox update manager has an easy to understand domain model that is shown in the UI. There are extensions. An extension has an icon, a description and a set of preferences (yes the preferences of each extensions is available directly from the "Extensions" dialog. In eclipse there's no way to find out what an extension contributes to eclipse. See my blog entry "When seamless integration becomes a nightmare..."). Anyway, hit a simple button to check for updates. It's done in seconds (not minutes like eclipse). Once downloaded, you can update the plugins you want to update.

If you don't like an extension you can select an extension and "Uninstall" it. Something that is not possible with the eclipse update manager. Eclipse is a grow only system -- no way to remove features. Like windows in the old days. Once you have installed a feature there's no way to get rid of it. Only, if you regularly do backups (like I do), you can revert a previous version of eclipse by reverting a backup. But eclipse itself is grow only (*). If you have installed a few features you don't like and you cannot get rid of, you will start thinking twice if you want to install a new plugin. That's very bad for the eclipse ecosystem.

Eclipse must solve the update manager problem soon and provide a simple to use and understandable update manager that solves the problems of eclipse users.

Domain Driven Design could help come up with a update manager domain model that is relevant for eclipse users...

Michael

(*) You could also use separate extension locations for each feature you install and simply delete the location if you want to uninstall the extension. But that's a hack. The update manager (UI) does not even support dropping of extensions. I tried that for a while, but it requires a lot of discipline.