Re: [platform-update-dev] Install/Update API

["Bob Foster" <bob@xxxxxxxxxx>]

Long latency on this, I know, but I hope some consideration is given to
allowing plug-ins to selectively "opt out" of shared installs when the
plug-in license only covers single-person use. A plugin should/must be able
to require that it not be installed in a shared eclipse unless its license
permits. IOW, the update feature should not facilitate piracy.

Bob Foster

----- Original Message ----- 
From: "Mark Kralj-Taylor" <mark.kralj-taylor@xxxxxxxxx>
To: <platform-update-dev@xxxxxxxxxxx>
Sent: Thursday, October 16, 2003 3:05 AM
Subject: Re: [platform-update-dev] Install/Update API


Message
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.

        [platform-update-dev] Install/Update API

    a.. From: Dejan Glozic <dejan@xxxxxxxxxx>
    b.. Date: Mon, 6 Oct 2003 16:24:56 -0400
    c.. Delivered-to: platform-update-dev@xxxxxxxxxxx

----------------------------------------------------------------------------
--


Poll:

The Eclipse Install/Update team would like to know of any and all cases
where the current (2.1) Update API is used. Note that we are only
interested in programmatic uses (i.e. referencing any of the non-internal
classes in org.eclipse.update.core plug-in) and not actually using features
and/or update sites.

Please send your answers to platform-update-dev mailing list only.

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Platform Components
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4854



  --

  NOTICE: If received in error, please destroy and notify sender.  Sender
does not waive confidentiality or privilege, and use is prohibited.