[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Java WebStart installer for Eclipse
|
Hi,
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.
We used this way to create the typical Eclipse plugin directory
structure on the local disk:
- One jar file per plugin
- One jar file for the main launcher class
Each of those jar files was mentioned inside the single jnlp file for
the Eclipse application (pros and cons see below). The main launcher
application extracted every plugin jar into the plugin directory.
To find the plugin jar files on the disk we used the class of the main
launcher via getResource. therefore we needed the name of each plugin.
Those names were given to the main launcher via argument definitions
inside the jnlp description. That means also, that each plugin was
mentioned twice inside the jnlp file (the jar file as resource and the
name argument).
I am not sure whether this is a portable way or not, but it works fine
on or Windows installations. But I would agree that this is not the best
solution if the spec does not garantee that all jar files for an
application are stored locally in the same directory.
(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.
I am not familiar enough with the installer extensions to decide this.
But I would be happy to hear something about it. :-)
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().
(e) Use a dir that is defined in the jnlp file. ;-)
The reason for this (extremely not web start compatible) way was that
the organization had defined a fixed installation path for the
application. This path was also used hard-coded inside a part of the
application (horrible implementation and I am glad that this part was
not written from my team).
...
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.
That would be a nice new use case for the update mechanism of Eclipse, I
think. It should be possible to use the update mechanism without SWT
just for automatic and silent updates of the system. This could, for
example, be called at every startup.
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.
Sounds great. I am highly interested in this code and would be very
happy to see it.
Best regards,
Martin
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
