Update Manager 2.0

What is the problem with the Eclipse Update Manager?

It is old: it was coded between Eclipse 1.x and Eclipse 2.x and has received little love since, for almost 4 years
It is brittle: networking connections and files operations are not reliable
It is ugly: the Update UI was never designed to be usable, rather more as an example of the feature that update can handle
It is complex: the update.core plugins contains more than 250 classes, update.ui about 100. the total update plugins set is over 400 classes. In contrast org.eclipse.osgi (which contain the OSGi kernel and the Eclipse adaptor to OSGi) has a bit over 300 classes.
It is buggy: see the 500+ pending bugs at Eclipse
It is a top ranked Eclipse annoyance
Until recently it was not used by Eclipse committers
It has been receiving little resource in the platform team, and past committers involved with it did loose motivation
Major Eclipse contributors try NOT to use it: for instance IBM created something called RPU (Rational Product Updater) that builds on top of a limited set of update manager features, yet does not use it fully. They must have their reason, since IBM contributed that code in the first place.
It promotes concepts which are out-of-sync with the modern OSGi-based Eclipse platform. Some example include the semantics for features versions, or feature to feature dependencies, which do not match the OSGi semantics. This results in many weirdness and issues, one of them being the difficulty to properly resolved required dependencies
It mixes widly orthogonal (albeit related) concepts of installed configuration management, plugins update and plugin installation. This results in an overly complex internal model
It mixes network and file operations with UI
It is not friendly to shared Eclipse installation, especially on Linux
It tries to handle too many exotic uses cases (for example supporting various pluggable update site types, or update policies) yet fails to handle the simple ones: update reliably an installed Eclipse environment
Some essential Eclipse pieces cannot be updated: the eclipse executable, the config.ini, the startup.jar, and so on.
It promotes by default messy installs (everything in one folder)
It does not handle multiple transports beyond HTTP out of the box, like BitTorrent, FTP, SFTP.
It does not provide suspendable/resumable operations: an update succeed or fails. In case of failure, you may be able to restart everything at square one, or are left with an installation in an undetermined state
It provides XML documents schemas which are hardcoded and inflexible. For instance you can add an attribute to an existing element of the site.xml, yet you cannot add a new element without breaking compatibility.
It is not friendly to RCP applications, which often re-implement a UI, or try to avoid it.

Yet:

This is an important and useful feature

Now, what can we do about it?

patch, fix and enhance to make it work: with over 500 pendings bugs and a complex code and model, this is a huge undertaking that would require
pltform committers involvement, and a committment from Eclipse PMC. It does not sounds likely
redo it from scratch: this is appealing and is more or less in the platform plan for Eclispe 3.3 under the theme or "Provisioning". This will take time to get there though.
take a middle of the road approach:

re-use some essentials pieces to be compatible (for example reuse the parsers for site, mirrors, and feature manifests)
provide a new UI loosely inspired from the Firefox theme update UI and the MacOSX Software Update
provide a simpler internal model as a facade to the excessively complex UM model
separate cleanly the UI, core and network operations
provides reliable HTTP operation, and later BitTorrent using the clean room BitTorrent done during the Google Summer of Code
makes things that are simple easy, and things that are complex possible, possibly delegating to the legacy update manager in those cases

This later approach is the one we are trying to deliver.

There is some very early non-working code that you can view here .

The people

Folks involved are:

Kenny Tschang
Philippe Ombredanne (pombredanne {at} users.sf.net)
Francois Granade
Benjamin Muskalla (b.muskalla [at] gmx.net)

If you are interested to participate or contribute, this is an open effort; please contact Philippe or add your name here. Join us on IRC

The fun

The fun is mostly on IRC on #eclipse and #easyeclipse.

We also want to keep the Eclipse platform team in the loop.

Seee that thread for a start.

Related Chatlogs:

2006-09-13- starting at 22:30 : a walkthrough of the code and some of the concepts already in place

Last Modified 12/5/06 7:35 AM

Hide Tools

Site
Changes
Index
Search

User
Log In
Register