[platform-core-dev] Java WebStart installer for Eclipse

["Martin Buechi" <Martin.Buechi@xxxxxxxxxxxxxxx>]

Martin Lippert,

Since you had already written a Java WebStart-based installer for a pure
Java project using the Eclipse plugin framework, I thought you might be able
to shed some light on which of the following ideas work. Of course, I am
also keen on receiving comments from anybody else.

1. I decided to create an installer that creates the typical Eclipse plugin
structure on disk rather than modify the Eclipse plugin framework to work
from jars. This seems better given the limited amount of time, the
distribution to users who are willing to grant my code all permissions, and
the lack of resources to maintain the patch for future Eclipse versions.

2. Two things need to be downloaded (initially and checked for updates): The
installer class and the Eclipse plugins. The installer class is naturally
downloaded using JNLP (inside the main jar). For the Eclipse plugins I see
two options:

(a) JNLP by adding the corresponding jar(s) to the JNLP file. I don't see a
portable (guaranteed by the specification) way to find the location of the
downloaded file(s) on disk so I can extract them. To get the jars of the
individual plugins, they could be packaged inside an outer jar that also
contains the names of all contained jars (The single deployable zip file
feature format is an ideal candidate for this.). They can then be unpacked
by using ClassLoader.getResourceAsStream(). When the application is launched
again, check based on date whether and which plugins have been updated in
the downloaded jar and update.

(b) Have my installer download them. The location and names from which to
download can be in a properties file inside the installer archive.
Alternatively, the base location could also be obtained via
javax.jnlp.BasicService.getCodeBase(). In this scenario, the up-to-date
check has to be made before downloading them using the timestamp from the
HTTP get request (unless versions are specified, this is what the JNLP
client does in (a)).

I am undecided as to which option is better. I am unclear as to whether an
installer extension (installer-desc, see p 20 of the JNLP spec) would be of
any use here.

3. I see three options for packaging: all Eclipse plugins inside single jar,
one jar per feature (which probably ends up being the same since I deploy
most apps as one feature), or one jar per plugin. I guess it is a tradeoff
between simplicity (one line in JNLP file) vs efficient updates if only some
plugins have changed (and there is no support for diffs).

My take is to go with one jar per feature.

4. I see multiple options for determining the installation location:
(a) Ask the user.
(b) Use the user.dir property.
(c) User the jnlpx.deployment.user.home property. This seems to be set in
Sun's implementations of Java WebStart, but not guaranteed to exist by the
spec.
(d) Use a installer-desc and then use ExtensionInstallerService.
getInstallPath().

My take is to go with (a) or (b) depending upon the knowledge of the
targeted user base. Savvy users may prefer to be able to define themselves
the location. Others might feel inclined to call tech support to check their
company policy.

5. For options (a) and (d), and possibly also (b) and (c), in 4 the
installer has to store the installation location. I see two options:
(a) javax.jnlp.PersistenceService (which is optional according to the
specification) or
(b) JDK 1.4 (my target) java.util.prefs.Preferences.

I plan to go with approach (b).

An alternative for the updates would be to use the Eclipse platform update
manager with features and use WebStart only for the initial install. But
that would require additional Eclipse plugins and the GUI would require SWT.
Furthermore, automatic update is desirable in my applications.

Does this make sense or are there better approaches that I have overlooked?

I plan to write this code for my employer and then share it under CPL, in
case anyone else is interested in it.

Regards,

Martin

> -----Original Message-----
> From: platform-core-dev-admin@xxxxxxxxxxx [mailto:platform-core-dev-
> admin@xxxxxxxxxxx] On Behalf Of Martin Lippert
> Sent: Sunday, March 23, 2003 7:53 AM
> To: platform-core-dev@xxxxxxxxxxx
> Subject: Re: [platform-core-dev] Use of Eclipse plugin framework in pure
> Java applications
> 
> Hi all,
> 
> >>We used WebStart to deploy an Eclipse-plugin-based application.
> >>Therefore we build a special startup class that configures the plugin
> >>directory with the downloaded jars and starts the Eclipse launcher.
> >>Works fine!
> >
> >
> > Would you be willing to share this startup class under a CLP, Apache, or
> BSD
> > license?
> I am sorry but unfortunately we had developed this functionality for one
> of our customers within a consulting project. Therefore the code does
> not belong to us. It would only be possible to rewrite that class, which
> remains an option.
> 
> > I see the pros and cons of this vs a modification of the eclipse core as
> > follows:
> >
> > + No need to modify eclipse and repeat these changes for each new
> version of
> > eclipse until JNLP support has been developed in Equinox and integrated
> into
> > the main eclipse branch.
> >
> > - Need additional security permission, even for applications that could
> > otherwise run in the default sandbox.
> 
> I agree.
> 
> Best regards,
> Martin
> 
> 
> 
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-core-dev

BEGIN:VCARD
VERSION:2.1
N:Buechi;Martin
FN:Martin Buechi, Ph.D.
ORG:ChoiceMaker Technologies
TITLE:Chief Software Architect
TEL;WORK;VOICE:(212) 905-6033
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;41 East 11th Street=0D=0A11th floor;New York;NY;10003;United States of Ame=
rica
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:41 East 11th Street=0D=0A11th floor=0D=0ANew York, NY 10003=0D=0AUnited Stat=
es of America
URL;WORK:http://www.choicemaker.com
EMAIL;PREF;INTERNET:Martin.Buechi@xxxxxxxxxxxxxxx
REV:20010622T032847Z
END:VCARD