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

["John Arthorne" <John_Arthorne@xxxxxxxxxx>]

If you're looking for feedback from the eclipse install/update team, you'd be better off moving this discussion to the platform-update-dev mailing list. 
--

Martin Lippert <lippert@xxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 04/13/2003 10:19 AM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        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.


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