[news.eclipse.technology.equinox] Re: classes fordynamic plugin events

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

Yes, this area is confusing (features/configurations/plugins...).  Basically
features are collections of plugins. They are interesting to the user as
well as the product developer/deployer in that they allow for abstraction.
I don't need to know about all 328 plugins in product A, I just need to know
that its root feature is FeatureA.  So product managers create features and
users install features.  This is powerful.

At runtime we are interested in what code to run and what extensions go into
which extension points. These are plugin notions.  Features help to define
the scope of plugins to consider while building the registry but beyond
that, contribute nothing to the runtime picture.

This is why you see some areas which talk about feature and some which do
not.  Think of it like JARs in Java systems.  Users (generally)
download/install/manage JARs.  The VM init code takes JARs from the
classpath and populates classloaders.  The runtime however does not care
about any of this.  I just needs the bytes for the classes.

The current implementation is more complicated than needed/desired.
However, there is an underlying thrust that is important (IMHO).  Features
are not a runtime concept.  They are used by the PlatformConfiguration to
figure out which plugins are relevant but after that list has been computed,
the runtime proper takes the list and starts.

Having said that, there does seem to be dynamic plugins work to be done in
the PlatformConfiguration area.

Jeff



"Olivier Gruber" <ogruber@xxxxxxxxxx> wrote in message
news:b620ub$3b2$1@xxxxxxxxxxxxxxxx
> Hi Mel,
>
> One a specific point... the configuration... well, things are not that
> clear. See below...
>
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Mel Martinez" <melm@xxxxxxxxxx> wrote in message
> news:b5tgsj$nau$1@xxxxxxxxxxxxxxxx
> > Next on the agenda, we jump upstream and try to figure out where the
> > changes to the PluginRegistry are coming from.  I'm still learning the
> > lay of the land, but it seems to me they are coming from any changes to
> > the PlatformConfiguration, sincej (according to the javaodocs) the
> > IPlatformConfiguration "Represents the runtime configuration used by the
> > Eclipse platform. Any configuration changes do not take effect until
> > next startup of the Eclipse platform".
> >
> > The org.eclipse.core.internal.boot.PlatformConfiguration is the beast
> > responsible for finding all the features that need to be loaded which
> > then lead to the plugins that need to be loaded.  I say beast because
> > this is one heck of a 'BLOB' class.  This class has about 2031 fields,
> > 43 million methods and a half-dozen internal classes (*shudder*).  Man,
> > does it SCREAM for refactoring.
>
> Could not agree more... but actually, this is the least of our problem...
> Our main concern is that Eclipse has so many ways to bootstrap...
> and obtain its plugins or its features... as directories... as URLs,
> or as a combination... I am still quite fighting with understanding boot
> and all its bootstrap cases...
>
> The most interesting aspect though is that boot, through
> PlatformConfiguration, knows about features... and shows a somewhat
> clean interface to what the configuration is... but then it vanishes at
> the runtime plugin level... which takes a list of URLs for its plugin
> path...
> The entire plugin registry is oblivious to features... and they show back
> up in the update manager.
>
> So one of the first decision before anything else is to decide
> if features are first-class runtime concepts or not. Given how
> the plugin registry is now sandwitched between boot and update
> plugins... Does it make sense to have the plugin registry ignore
> features?
>
> I would also argue that boot could be much cleaner if it would
> always boot through a configuration file... as opposed to the
> multitude of cases it handles now. Beside historical reasons,
> I don't see why we should keep all those special cases around?
>
> Also, I would argue that up from the boot plugin... Equinox
> should use that PlatformConfiguration... this would apply to
> runtime and update plugins at the very least. I haven't been able
> to convince myself that update manager uses PlatformConfiguration
> to installs plugins... Can someone confirms it ?
>
> Best regards,
>
>