Re: [equinox-dev] Re: boot class path extension bundles in Eclipse/Equin

[Thomas Watson <tjwatson@xxxxxxxxxx>]

> Jay,
> 
> Technically, any file can be deployed via a feature/bundle. The only
real
> issue is how one gets the jar into the xbootclasspath at startup.
 

The OSGi R4 specification does define a way to do
this with what is called
boot classpath extension bundles.  These bundles
act as fragments to the 
system.bundle and they can specify additional libraries
that can be 
appended to the boot classpath.

> As you
> know, the IBM WMC version of the RCP uses a configuration file to
configure
> the launch environment and that can be modified via feature installhandler
> to add a jar contained in some bundle to the boot classpath, thus
meaning
> any file, including boot path jars, can be updated.
> 

This sound very similar to the <launcher>.ini
file that is supplied with 
eclipse to configure the eclipse launcher.  The
problem I see with this 
approach is the use of install handlers that must
be intimately aware of the 
framework.  For example, how does it know what
order to put the jars on the 
boot classpath.  The boot classpath extensions
spec in OSGi R4 handles these 
details for you.

> I guess you are really asking if Equinox/Eclipse should be providing
some
> similar capability for 'standard' eclipse.  Is that correct?
 In that case,
> that's a fair thing to ask.
> 
> This topic sort of crosses over into the dev-update list, because
it covers
> update, but since this is also 'new ground' for platform lifecycle,
it does
> probably need to be vetted here as well.

Yup, I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=127724

to consider implementing boot classpath extensions.

> One of the key aspects that enables the 'updating of everything' in
the WMC
> architecture is to use a two-stage launch.  The first launcher
process,
> which terminates as a process after it is done, includes code to finish
and
> clean up install/update steps that affect the launch of the runtime
> process.  The main task of the first launch phase is to configure
the
> launch environment for the runtime process.  Because the first
launcher is
> not running during the runtime, it can itself be changed during an
update.
> 
> Is it time to start talking about incorporating any of these ideas
into
> eclipse?
> 
> [Side note - Andrew Davis will be doing a short 'lightening talk'
on
> 'updating the entire world' at EclipseCon.  I can't be there,
but Andrew
> will go over some of the techniques that we use to make it possible
to
> update every single aspect of the system.]
> 
> -mel
>