I needed to code against the Eclipse 2.1 update API
to facilitate deployment of Eclipse, WSAD and a mix of open source and in-house extension features/plugins to a read-only file system accessed by
Widows, Linux and Solaris desktops.
Before writing this code I exchanged some emails
with the platform-update-dev mail group
(answered by Christophe Eleck).
We are really hoping that Eclipse 3.0 will
avoid the need for our code entirely, so this sounds a good point to explain our
use case again:
- To reduce deployment and maintenance costs we
avoid local installs.
- Instead we provide applications like Java and
Eclipse on a global, READ-ONLY file system.
- Users do not install Eclipse on their local
machine, nor do we want users to download features from an update
site.
- We want to provide everything
centrally.
- To deploy an application we first package
it to a read-write 'dev' area, it is then turned-over to the read-only 'dist' area.
So there is a difference in path prefixes between
where an application is packaged, and where it is run from. It is important to us that this doesn't cause
problems for the 'eclipse -install' process (e.g. storing full paths in platform
meta-data)
- Each user has their own read-write Eclipse
workspace directory under their home directory.
The Eclipse update mechanism is important to us
because it lets users pick which extra features they opt-into, in
'their' Eclipse experience.
To make the Eclipse update mechanism work in our
read-only 'dist' environment, I added an 'Add local extension install site' action to the 'Eclipse Platform'
object in the 'Install Configuration' tree view. This lets you add a
pre-existing extension directory.
Eclipse 2.1 has several
extension site types, tagged by dot files. I found that an update manager site,
tagged with a '.eclipseUM' file worked best. However because the update manager
checks that .eclipseUM update sites are writeable, I had to cut-paste-modify
code, rather than simply call the update manager API.
For the user it is a 2 step
process to use a feature from a read-only extension install
site:
1) add read-only extension
install site
2) enable desired feature(s)
from the extension install site
(remembering to press the 'show
disabled features' button first)
There is a problem with our
approach. Where we
have provided several features in one extension install site, intending that
users can enable/disable features within the site independently. After
restarting Eclipse all features from the extension site can be enabled, not just
the ones the the user actually selected.
I hope Eclipse 3.0 will provide
better support for shared installs of Eclipse, so we don't need the code I have
attached.
Specifically:
- Continued support for shared
install of Eclipse in a read-only file-system.
(with no absolute paths embedded in any platform
meta-data, so we can copy from 'dev' to
'dist' areas)
- Support for users
adding (importing) shared extension sites from a read-only file system (without
copying).
- Externalising
platform configuration information, to a user
visible/editable/copyable XML file in user's Eclipse workspace. This file would
include what extension sites the user has added and which features from them are
enabled.
(we find that
Eclipse workspace can get corrupted, and some want multiple workspaces, in both
cases want to minimise time taken to duplicate a
workspace setup)
-- Other information
could be provided in human readable/editable files in workspace
dir:
- locations
of project directories
- eclipse
startup and JVM options - handled by Eclipse boot launcher executable, this
would be more user friendly than using long command line.
- how long
would it take to auto export .epf preferences on a clean shutdown, so if
workspace gets corrupt, a user always has a recent copy to restore preferences
from?
Mark.