Home » Eclipse Projects » Equinox » Detailed items for dynamic plugins
| Detailed items for dynamic plugins [message #6027] |
Mon, 03 March 2003 15:05  |
 Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
Hi,
As you might have guest by Jeff's message about the population of the CVS
repo,
the first problem we are interesting in tackling is the dynamic plugins.
We will start on this topic because parts of it are comitted items for 2.2,
however
this is not restrictive and feel free to experiment on the other fronts.
This problem can be split in 4 sub-problems listed below:
Plugin deactivation:
Here the goal is to avoid the memory to get cluttered with unsused
plugins.
So the all idea here, is to unload the plugin (instances, classes,
classloader)
to free memory. Once a plugin has been unloaded it can still be reloaded.
A few problems:
- how do we GC the instances,
- how do we tell the other plugins a plugin get deactivated,
- how do we GC the classloader,
- what should be done in the shutdown methods,
- is the plugin the right granularity to expose to a user to unload
- should the platform auto deactivate the plugins
- ....
Example: if a plugin providing menu entries is deactivated, menu entries
are still visible.
Plugin un-installation
Whereas the deactivation still gives the opportunity of reactivating a
plugin,
the plugin un-installation delete the plugin extensions and extension
points
from the registry.
A few problems:
- how do we change the content of the registry (deletion)
- how do we notify the other plugins about the uninstallation of the
plugin
- what can plugins do when a plugin is uninstalled
- ....
Example: if a plugin providing menu entries is un-installed, menu entries
are no longer visible.
Plugin installation
The goal of plugin installation is the reverse of the un-installation.
A user drop a plugin into the plugins directory, and ask for a "refresh",
the new plugin gets discovered and its extensions and extension-points
are made visible to the other plugins.
A few problems:
- how do we change the content of the registry (addition)
- how do we notify the other plugins about the installation of the
plugin
- what can plugins do when a plugin is discovered
- ...
Example: if the new plugin installed provides menu entries, menu entries
are made visible.
Plugin update
The goal is to provide the user to update a plugin without rebooting the
platform.
One 'simple' solution is to un-install then install the same plugin,
however this implies
loosing some information, and useless computation.
From the 4 items listed, we will start with the first one as it is forms the
basis for uninstall
and update.
PaScaL
|
|
|
| Re: Detailed items for dynamic plugins [message #6060 is a reply to message #6027] |
Mon, 03 March 2003 21:46  |
Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi PaScal... :-)
Good points... one first thing to look at is who has pointers within
a plug-in class loader, either on the class loader itself, a loaded class,
or instances of a loaded class... we will understand better how to
allow the GC to collect the loader, the loaded classes, and their instances.
As you know, there is no way to force in a JVM the GC of an object
(isn't that why we have a GC in the first place :-)
So we need to make sure all the references to any object or class
inside the class loader is cut. This means that we have to track
their current usage... to get an idea.
Since there is no limit on how references can be passed across plug-ins...
we will need to ultimately rely on a callback to plug-ins to let those
references go...
The simplest is to callback all plug-ins...
Is there a way to optimize here, is there a way to know which plug-ins
may have a reference ? Seems difficult to me...
Because even if we consider the plug-ins who transitively require a given
plug-in... we are still likely to miss someone... since references can be
passed around as Object, as super classes, or as interfaces, without
requiring
a direct knowledge of the dynamic class of the object.
Ok, in all cases, we will never be sure that the class loader goes away.
Hence, we need to be sure that we reuse it if it is still around and the
plug-in
is re-activated... this is a school-book example of using soft references...
we will have to keep the soft reference on the class loader and reuse the
loader upon reactivating the plug-in if it is still there.
This will also allow us to check if the loader is actually going away.
If it is not, we know someone still has a reference... but we don't know
who... :-(
Unless we use a tool like Jinsight, a cool tool for Java memory leaks...
from a temporary tool-related time warp in my life as a low-level system
guy... :-)
So, who knows the ins and outs of extensions and extension points ?
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b3vr8q$2h8$1@rogue.oti.com...
> Hi,
>
> As you might have guest by Jeff's message about the population of the CVS
> repo,
> the first problem we are interesting in tackling is the dynamic plugins.
> We will start on this topic because parts of it are comitted items for
2.2,
> however
> this is not restrictive and feel free to experiment on the other fronts.
>
> This problem can be split in 4 sub-problems listed below:
>
> Plugin deactivation:
> Here the goal is to avoid the memory to get cluttered with unsused
> plugins.
> So the all idea here, is to unload the plugin (instances, classes,
> classloader)
> to free memory. Once a plugin has been unloaded it can still be
reloaded.
> A few problems:
> - how do we GC the instances,
> - how do we tell the other plugins a plugin get deactivated,
> - how do we GC the classloader,
> - what should be done in the shutdown methods,
> - is the plugin the right granularity to expose to a user to unload
> - should the platform auto deactivate the plugins
> - ....
>
> Example: if a plugin providing menu entries is deactivated, menu entries
> are still visible.
>
>
> Plugin un-installation
> Whereas the deactivation still gives the opportunity of reactivating a
> plugin,
> the plugin un-installation delete the plugin extensions and extension
> points
> from the registry.
> A few problems:
> - how do we change the content of the registry (deletion)
> - how do we notify the other plugins about the uninstallation of the
> plugin
> - what can plugins do when a plugin is uninstalled
> - ....
>
> Example: if a plugin providing menu entries is un-installed, menu
entries
> are no longer visible.
>
>
> Plugin installation
> The goal of plugin installation is the reverse of the un-installation.
> A user drop a plugin into the plugins directory, and ask for a
"refresh",
> the new plugin gets discovered and its extensions and extension-points
> are made visible to the other plugins.
> A few problems:
> - how do we change the content of the registry (addition)
> - how do we notify the other plugins about the installation of the
> plugin
> - what can plugins do when a plugin is discovered
> - ...
>
> Example: if the new plugin installed provides menu entries, menu entries
> are made visible.
>
>
> Plugin update
> The goal is to provide the user to update a plugin without rebooting the
> platform.
> One 'simple' solution is to un-install then install the same plugin,
> however this implies
> loosing some information, and useless computation.
>
>
> From the 4 items listed, we will start with the first one as it is forms
the
> basis for uninstall
> and update.
>
> PaScaL
>
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #6076 is a reply to message #6060] |
Tue, 04 March 2003 03:48 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
All that sounds great. We "just" need to make it happen :-)
I'd like to emphasize that the notification mechanism for plugins must be
transparent:
- By default, plugins must still work without modification. Obviously
they will
be very unlikely to be unloaded.
- Plugin that will do the effort to "implement" the notification
mechanism will then
be unloadable (of course it is only true, if no one keeps reference on
it...)
As a first objective, I propose that we try to unload the "hello world
plugin", since
no one should refer to it.
I'm not sure I understood what you meant by "who knows the ins and outs of
extensions and extension points", but I would say it is the PluginRegistry
that you can access from Platform.
Then you have an API to run through it and find out which plugin provide an
extension, etc.
I don't see how this last information can be of any use for the first pb?
PaScaL
"Olivier Gruber" <ogruber@us.ibm.com> a
|
|
|
| Re: Detailed items for dynamic plugins - OSGi perspective [message #6106 is a reply to message #6027] |
Tue, 04 March 2003 09:51 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
From an OSGi perspective:
Deactivation. This is the hardest problem we are facing. Virtuall all
code is written without any cleanup in mind. This means that the
environment must be able to do cleanup of existing plugins, requiring a
general life cycle notification mechanism.
A full isolation of plugins is possible with the isolation API (see JSR
121) but this makes communication between plugins significantly more
expensive. (In the OSGi we extensively discussed proxying all objects
that are shared, but this was not done for performance reasons).
In Smalltalk (>20 years ago...), it was possible to iterate over all
references, which would allow some clean up and diagnostics.
Unfortunately, Java does not have such a feature.
The OSGi deactivation requires the participation of the bundle (the jar
file). A bundle has an activator that implements a start and stop
method. The Framework is aware of dependencies (package and service) and
will clean up as far as the VM allows. Dependent plugins will receive
notifications (service and bundle). We have a special ServiceTracker
class that makes this dependency handling quite painless for the programmer.
Most of the other features that are required should be implemented in
OSGi with the service registry. This is a generic registry that allows
participants to register any object under a number of interfaces/classes
together with a number of describing properties. Bundles can listen to
notifications from this registry for registering, modification and or
unregistering.
The Eclipse more specific registries should imho be build on top of the
generic (OSGi like) registry. I.e. a plugin should register a plugin
service in the generic registry that provides Eclipse specific
communication. (Alternatively, Eclipse could want the
installation/uninstallation of bundles and read configuration
information they carry in their bundle (JAR). This would allow Eclipse
to start/stop bundles on demand).
Installation of bundles is not defined in OSGi, only an (extensive
management) API is provided. This has resulted in a many of so called
Management Agents that provide the management of the environment. There
exists agents that watch a directory and install/uninstall depending on
what is in that directory. GUIs, consoles, provisioning systems (see JSR
124), and probably others. The agent can request information
(notifications as well) about packages, security, installed bundles,
dependencies etc. Obviously, a management agent is an ordinary bundle.
I strongly suggest Equinox follows a similar "policy free" path because
this is one of the most succesful aspects of OSGi imho.
Update is imho not an uninstall/install. In the OSGi model, a bundle has
its private data area that needs to be preserved. This private area
works very well because it allows a bundle to be uninstalled and its
data completely cleaned up. An update needs to preserve this area.
Further, an update needs special rollback semantics so that its outcome
is atomic. Doing an uninstall/install will make this much harder.
Last, but not least, I would like to make a case for static analysis.
Though any system should have well defined failure behavior, I think the
system can be kept simpler if failures are the exception and not the
rule. We should therefore have a system with enough declarative
information so that most failures can be caught before they happen.
Catching >95% of the error cases before install will allow a naive
implementation of recovery like for example a restart.
BTW, I want to make clear that Eclipse is a tremendous achievement that
has gone a long way. I hope that we can find a way to create a
cooperation between Eclipse and OSGi, which should be possible because I
think the products are complimentary and not overlapping. The OSGi is a
democratic process but if changes are needed, there will be several
companies willing to work for such changes.
Kind regards,
Peter Kriens
Pascal Rapicault wrote:
> Hi,
>
> As you might have guest by Jeff's message about the population of the CVS
> repo,
> the first problem we are interesting in tackling is the dynamic plugins.
> We will start on this topic because parts of it are comitted items for 2.2,
> however
> this is not restrictive and feel free to experiment on the other fronts.
>
> This problem can be split in 4 sub-problems listed below:
>
> Plugin deactivation:
> Here the goal is to avoid the memory to get cluttered with unsused
> plugins.
> So the all idea here, is to unload the plugin (instances, classes,
> classloader)
> to free memory. Once a plugin has been unloaded it can still be reloaded.
> A few problems:
> - how do we GC the instances,
> - how do we tell the other plugins a plugin get deactivated,
> - how do we GC the classloader,
> - what should be done in the shutdown methods,
> - is the plugin the right granularity to expose to a user to unload
> - should the platform auto deactivate the plugins
> - ....
>
> Example: if a plugin providing menu entries is deactivated, menu entries
> are still visible.
>
>
> Plugin un-installation
> Whereas the deactivation still gives the opportunity of reactivating a
> plugin,
> the plugin un-installation delete the plugin extensions and extension
> points
> from the registry.
> A few problems:
> - how do we change the content of the registry (deletion)
> - how do we notify the other plugins about the uninstallation of the
> plugin
> - what can plugins do when a plugin is uninstalled
> - ....
>
> Example: if a plugin providing menu entries is un-installed, menu entries
> are no longer visible.
>
>
> Plugin installation
> The goal of plugin installation is the reverse of the un-installation.
> A user drop a plugin into the plugins directory, and ask for a "refresh",
> the new plugin gets discovered and its extensions and extension-points
> are made visible to the other plugins.
> A few problems:
> - how do we change the content of the registry (addition)
> - how do we notify the other plugins about the installation of the
> plugin
> - what can plugins do when a plugin is discovered
> - ...
>
> Example: if the new plugin installed provides menu entries, menu entries
> are made visible.
>
>
> Plugin update
> The goal is to provide the user to update a plugin without rebooting the
> platform.
> One 'simple' solution is to un-install then install the same plugin,
> however this implies
> loosing some information, and useless computation.
>
>
> From the 4 items listed, we will start with the first one as it is forms the
> basis for uninstall
> and update.
>
> PaScaL
>
>
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #6121 is a reply to message #6027] |
Tue, 04 March 2003 09:55 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Could we have a wiki-wiki or similar on the Eclipse web site? This will
make it a bit easier to remember the issues and resolutions? I am not
sure to ask but this list is a prime candidate for wiki-wiki site
Kind regards,
Peter Kriens
Pascal Rapicault wrote:
> Hi,
>
> As you might have guest by Jeff's message about the population of the CVS
> repo,
> the first problem we are interesting in tackling is the dynamic plugins.
> We will start on this topic because parts of it are comitted items for 2.2,
> however
> this is not restrictive and feel free to experiment on the other fronts.
>
> This problem can be split in 4 sub-problems listed below:
>
> Plugin deactivation:
> Here the goal is to avoid the memory to get cluttered with unsused
> plugins.
> So the all idea here, is to unload the plugin (instances, classes,
> classloader)
> to free memory. Once a plugin has been unloaded it can still be reloaded.
> A few problems:
> - how do we GC the instances,
> - how do we tell the other plugins a plugin get deactivated,
> - how do we GC the classloader,
> - what should be done in the shutdown methods,
> - is the plugin the right granularity to expose to a user to unload
> - should the platform auto deactivate the plugins
> - ....
>
> Example: if a plugin providing menu entries is deactivated, menu entries
> are still visible.
>
>
> Plugin un-installation
> Whereas the deactivation still gives the opportunity of reactivating a
> plugin,
> the plugin un-installation delete the plugin extensions and extension
> points
> from the registry.
> A few problems:
> - how do we change the content of the registry (deletion)
> - how do we notify the other plugins about the uninstallation of the
> plugin
> - what can plugins do when a plugin is uninstalled
> - ....
>
> Example: if a plugin providing menu entries is un-installed, menu entries
> are no longer visible.
>
>
> Plugin installation
> The goal of plugin installation is the reverse of the un-installation.
> A user drop a plugin into the plugins directory, and ask for a "refresh",
> the new plugin gets discovered and its extensions and extension-points
> are made visible to the other plugins.
> A few problems:
> - how do we change the content of the registry (addition)
> - how do we notify the other plugins about the installation of the
> plugin
> - what can plugins do when a plugin is discovered
> - ...
>
> Example: if the new plugin installed provides menu entries, menu entries
> are made visible.
>
>
> Plugin update
> The goal is to provide the user to update a plugin without rebooting the
> platform.
> One 'simple' solution is to un-install then install the same plugin,
> however this implies
> loosing some information, and useless computation.
>
>
> From the 4 items listed, we will start with the first one as it is forms the
> basis for uninstall
> and update.
>
> PaScaL
>
>
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #6134 is a reply to message #6121] |
Tue, 04 March 2003 16:32 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Great idea! :-) We are working on creating an Equinox wiki. It will be a
week or so however as our infrastructure team is swamped with work.
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E647814.9050309@aQute.se...
> Could we have a wiki-wiki or similar on the Eclipse web site? This will
> make it a bit easier to remember the issues and resolutions? I am not
> sure to ask but this list is a prime candidate for wiki-wiki site
>
> Kind regards,
>
> Peter Kriens
>
> Pascal Rapicault wrote:
>
> > Hi,
> >
> > As you might have guest by Jeff's message about the population of the
CVS
> > repo,
> > the first problem we are interesting in tackling is the dynamic plugins.
> > We will start on this topic because parts of it are comitted items for
2.2,
> > however
> > this is not restrictive and feel free to experiment on the other fronts.
> >
> > This problem can be split in 4 sub-problems listed below:
> >
> > Plugin deactivation:
> > Here the goal is to avoid the memory to get cluttered with unsused
> > plugins.
> > So the all idea here, is to unload the plugin (instances, classes,
> > classloader)
> > to free memory. Once a plugin has been unloaded it can still be
reloaded.
> > A few problems:
> > - how do we GC the instances,
> > - how do we tell the other plugins a plugin get deactivated,
> > - how do we GC the classloader,
> > - what should be done in the shutdown methods,
> > - is the plugin the right granularity to expose to a user to unload
> > - should the platform auto deactivate the plugins
> > - ....
> >
> > Example: if a plugin providing menu entries is deactivated, menu
entries
> > are still visible.
> >
> >
> > Plugin un-installation
> > Whereas the deactivation still gives the opportunity of reactivating a
> > plugin,
> > the plugin un-installation delete the plugin extensions and extension
> > points
> > from the registry.
> > A few problems:
> > - how do we change the content of the registry (deletion)
> > - how do we notify the other plugins about the uninstallation of the
> > plugin
> > - what can plugins do when a plugin is uninstalled
> > - ....
> >
> > Example: if a plugin providing menu entries is un-installed, menu
entries
> > are no longer visible.
> >
> >
> > Plugin installation
> > The goal of plugin installation is the reverse of the un-installation.
> > A user drop a plugin into the plugins directory, and ask for a
"refresh",
> > the new plugin gets discovered and its extensions and extension-points
> > are made visible to the other plugins.
> > A few problems:
> > - how do we change the content of the registry (addition)
> > - how do we notify the other plugins about the installation of the
> > plugin
> > - what can plugins do when a plugin is discovered
> > - ...
> >
> > Example: if the new plugin installed provides menu entries, menu
entries
> > are made visible.
> >
> >
> > Plugin update
> > The goal is to provide the user to update a plugin without rebooting
the
> > platform.
> > One 'simple' solution is to un-install then install the same plugin,
> > however this implies
> > loosing some information, and useless computation.
> >
> >
> > From the 4 items listed, we will start with the first one as it is forms
the
> > basis for uninstall
> > and update.
> >
> > PaScaL
> >
> >
> >
> >
>
|
|
|
| Re: Detailed items for dynamic plugins [message #6196 is a reply to message #6027] |
Tue, 04 March 2003 19:26 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi PaScal,
In a previous posting, I talk about references on classes, instances
and class loaders... for the deactivation/unloading to happen...
There is another aspect when considering dynamic loading and
unloading, that does not show up with deactivation...
a predictable behavior of the platform which Eclispe does not have
today. Sorry... :-)
Eclipse is a great platform and have done incredible in promoting
modular tool integration... but it is also true that the current component
model is error-prone and quite unpredictable. This is both a runtime and
tooling statement. The flaws are related to how plug-ins are build versus
executed, as well as how dependencies are expressed. The current approach
results in quite unpredictable behaviors, which leads to exceptions related
to class loading or hard-to-track bugs (especially with constant propagation
at compile time).
All those pathological cases I was able to build are based on the following
aspects of the component model:
- dependencies are expressed on plug-ins
- dependencies are transitive
- build-time dependencies may not match the runtime dependencies
- versionning interacts with class visibility at runtime.
The solution is to change the component model so that we can control
and predict the visibility rules, both at build and run time. The solution
for all of this is to move to an OSGi model, where imports and exports
are on specific Java packages, with versions. In other words, I am afraid
that we need to drop the current plug-in dependency scheme of Eclipse
in order to move to a practical solution to dynamic plug-ins.
Notice that I am saying moving to an OSGi model, not moving on top of
OSGi. This is not about accepting OSGi or not, for Eclipse per se,
the component model needs fixing to be a predictably robust platform.
Again, this is not an issue for deactivation, but it is an issue when
considering
dynamic loading/unloading of plug-ins. Extension management is one aspect,
ensuring consistent behavior regarding class loading is another.
PS:
I have tested some of the pathological cases, but I didn't want to send
yet another long posting... But I would be happy to describe them... :-)
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b3vr8q$2h8$1@rogue.oti.com...
> Hi,
>
> As you might have guest by Jeff's message about the population of the CVS
> repo,
> the first problem we are interesting in tackling is the dynamic plugins.
> We will start on this topic because parts of it are comitted items for
2.2,
> however
> this is not restrictive and feel free to experiment on the other fronts.
>
> This problem can be split in 4 sub-problems listed below:
>
> Plugin deactivation:
> Here the goal is to avoid the memory to get cluttered with unsused
> plugins.
> So the all idea here, is to unload the plugin (instances, classes,
> classloader)
> to free memory. Once a plugin has been unloaded it can still be
reloaded.
> A few problems:
> - how do we GC the instances,
> - how do we tell the other plugins a plugin get deactivated,
> - how do we GC the classloader,
> - what should be done in the shutdown methods,
> - is the plugin the right granularity to expose to a user to unload
> - should the platform auto deactivate the plugins
> - ....
>
> Example: if a plugin providing menu entries is deactivated, menu entries
> are still visible.
>
>
> Plugin un-installation
> Whereas the deactivation still gives the opportunity of reactivating a
> plugin,
> the plugin un-installation delete the plugin extensions and extension
> points
> from the registry.
> A few problems:
> - how do we change the content of the registry (deletion)
> - how do we notify the other plugins about the uninstallation of the
> plugin
> - what can plugins do when a plugin is uninstalled
> - ....
>
> Example: if a plugin providing menu entries is un-installed, menu
entries
> are no longer visible.
>
>
> Plugin installation
> The goal of plugin installation is the reverse of the un-installation.
> A user drop a plugin into the plugins directory, and ask for a
"refresh",
> the new plugin gets discovered and its extensions and extension-points
> are made visible to the other plugins.
> A few problems:
> - how do we change the content of the registry (addition)
> - how do we notify the other plugins about the installation of the
> plugin
> - what can plugins do when a plugin is discovered
> - ...
>
> Example: if the new plugin installed provides menu entries, menu entries
> are made visible.
>
>
> Plugin update
> The goal is to provide the user to update a plugin without rebooting the
> platform.
> One 'simple' solution is to un-install then install the same plugin,
> however this implies
> loosing some information, and useless computation.
>
>
> From the 4 items listed, we will start with the first one as it is forms
the
> basis for uninstall
> and update.
>
> PaScaL
>
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #6307 is a reply to message #6196] |
Tue, 04 March 2003 22:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Olivier,
I'm a little confused by how this would all work under the OSGi model
(importing/exporting packages, package versioning, ...). To help me (and
others?) understand can you provide actual bundle specifications for the
following plugins:
org.eclipse.core.runtime
org.eclipse.core.resources
org.eclipse.swt
org.eclipse.ui.* (if you can)
That should be a reasonable sampling of plugin interactions (feel free to
include others :-). The intent here is not to put you through lots of work
(I suspect you already have most of this done) but rather to put hard
concrete structure behind the story.
Perhaps put it on the website and point us at it?
Jeff
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b42uqp$ckm$1@rogue.oti.com...
> Hi PaScal,
>
> In a previous posting, I talk about references on classes, instances
> and class loaders... for the deactivation/unloading to happen...
> There is another aspect when considering dynamic loading and
> unloading, that does not show up with deactivation...
> a predictable behavior of the platform which Eclispe does not have
> today. Sorry... :-)
>
> Eclipse is a great platform and have done incredible in promoting
> modular tool integration... but it is also true that the current component
> model is error-prone and quite unpredictable. This is both a runtime and
> tooling statement. The flaws are related to how plug-ins are build versus
> executed, as well as how dependencies are expressed. The current approach
> results in quite unpredictable behaviors, which leads to exceptions
related
> to class loading or hard-to-track bugs (especially with constant
propagation
> at compile time).
>
> All those pathological cases I was able to build are based on the
following
> aspects of the component model:
>
> - dependencies are expressed on plug-ins
> - dependencies are transitive
> - build-time dependencies may not match the runtime dependencies
> - versionning interacts with class visibility at runtime.
>
> The solution is to change the component model so that we can control
> and predict the visibility rules, both at build and run time. The solution
> for all of this is to move to an OSGi model, where imports and exports
> are on specific Java packages, with versions. In other words, I am afraid
> that we need to drop the current plug-in dependency scheme of Eclipse
> in order to move to a practical solution to dynamic plug-ins.
>
> Notice that I am saying moving to an OSGi model, not moving on top of
> OSGi. This is not about accepting OSGi or not, for Eclipse per se,
> the component model needs fixing to be a predictably robust platform.
> Again, this is not an issue for deactivation, but it is an issue when
> considering
> dynamic loading/unloading of plug-ins. Extension management is one aspect,
> ensuring consistent behavior regarding class loading is another.
>
> PS:
> I have tested some of the pathological cases, but I didn't want to send
> yet another long posting... But I would be happy to describe them... :-)
>
> Best regards,
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
> news:b3vr8q$2h8$1@rogue.oti.com...
> > Hi,
> >
> > As you might have guest by Jeff's message about the population of the
CVS
> > repo,
> > the first problem we are interesting in tackling is the dynamic plugins.
> > We will start on this topic because parts of it are comitted items for
> 2.2,
> > however
> > this is not restrictive and feel free to experiment on the other fronts.
> >
> > This problem can be split in 4 sub-problems listed below:
> >
> > Plugin deactivation:
> > Here the goal is to avoid the memory to get cluttered with unsused
> > plugins.
> > So the all idea here, is to unload the plugin (instances, classes,
> > classloader)
> > to free memory. Once a plugin has been unloaded it can still be
> reloaded.
> > A few problems:
> > - how do we GC the instances,
> > - how do we tell the other plugins a plugin get deactivated,
> > - how do we GC the classloader,
> > - what should be done in the shutdown methods,
> > - is the plugin the right granularity to expose to a user to unload
> > - should the platform auto deactivate the plugins
> > - ....
> >
> > Example: if a plugin providing menu entries is deactivated, menu
entries
> > are still visible.
> >
> >
> > Plugin un-installation
> > Whereas the deactivation still gives the opportunity of reactivating a
> > plugin,
> > the plugin un-installation delete the plugin extensions and extension
> > points
> > from the registry.
> > A few problems:
> > - how do we change the content of the registry (deletion)
> > - how do we notify the other plugins about the uninstallation of the
> > plugin
> > - what can plugins do when a plugin is uninstalled
> > - ....
> >
> > Example: if a plugin providing menu entries is un-installed, menu
> entries
> > are no longer visible.
> >
> >
> > Plugin installation
> > The goal of plugin installation is the reverse of the un-installation.
> > A user drop a plugin into the plugins directory, and ask for a
> "refresh",
> > the new plugin gets discovered and its extensions and extension-points
> > are made visible to the other plugins.
> > A few problems:
> > - how do we change the content of the registry (addition)
> > - how do we notify the other plugins about the installation of the
> > plugin
> > - what can plugins do when a plugin is discovered
> > - ...
> >
> > Example: if the new plugin installed provides menu entries, menu
entries
> > are made visible.
> >
> >
> > Plugin update
> > The goal is to provide the user to update a plugin without rebooting
the
> > platform.
> > One 'simple' solution is to un-install then install the same plugin,
> > however this implies
> > loosing some information, and useless computation.
> >
> >
> > From the 4 items listed, we will start with the first one as it is forms
> the
> > basis for uninstall
> > and update.
> >
> > PaScaL
> >
> >
> >
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #6312 is a reply to message #6196] |
Wed, 05 March 2003 02:34 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
Could you describe here or on the website, what are your pathological cases.
I'm very curious...
If you could directly gives code, it would be even greater.
If you post on the website, do not forget to post the link
PaScaL
"Olivier Gruber" <ogruber@us.ibm.com> a
|
|
|
| Re: Detailed items for dynamic plugins [message #7689 is a reply to message #6307] |
Wed, 05 March 2003 15:21 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Jeff,
Let's do three things... in three postings.
1) I will reply to Pascal about pathological cases... so that we better
understand the
problem.
2) I will explain how the approach in OSGi solves it...
3) I will publish my bundle manifests...
Should be a good start.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b438uo$kn5$1@rogue.oti.com...
> Olivier,
>
> I'm a little confused by how this would all work under the OSGi model
> (importing/exporting packages, package versioning, ...). To help me (and
> others?) understand can you provide actual bundle specifications for the
> following plugins:
> org.eclipse.core.runtime
> org.eclipse.core.resources
> org.eclipse.swt
> org.eclipse.ui.* (if you can)
>
> That should be a reasonable sampling of plugin interactions (feel free to
> include others :-). The intent here is not to put you through lots of
work
> (I suspect you already have most of this done) but rather to put hard
> concrete structure behind the story.
>
> Perhaps put it on the website and point us at it?
>
> Jeff
>
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b42uqp$ckm$1@rogue.oti.com...
> > Hi PaScal,
> >
> > In a previous posting, I talk about references on classes, instances
> > and class loaders... for the deactivation/unloading to happen...
> > There is another aspect when considering dynamic loading and
> > unloading, that does not show up with deactivation...
> > a predictable behavior of the platform which Eclispe does not have
> > today. Sorry... :-)
> >
> > Eclipse is a great platform and have done incredible in promoting
> > modular tool integration... but it is also true that the current
component
> > model is error-prone and quite unpredictable. This is both a runtime and
> > tooling statement. The flaws are related to how plug-ins are build
versus
> > executed, as well as how dependencies are expressed. The current
approach
> > results in quite unpredictable behaviors, which leads to exceptions
> related
> > to class loading or hard-to-track bugs (especially with constant
> propagation
> > at compile time).
> >
> > All those pathological cases I was able to build are based on the
> following
> > aspects of the component model:
> >
> > - dependencies are expressed on plug-ins
> > - dependencies are transitive
> > - build-time dependencies may not match the runtime dependencies
> > - versionning interacts with class visibility at runtime.
> >
> > The solution is to change the component model so that we can control
> > and predict the visibility rules, both at build and run time. The
solution
> > for all of this is to move to an OSGi model, where imports and exports
> > are on specific Java packages, with versions. In other words, I am
afraid
> > that we need to drop the current plug-in dependency scheme of Eclipse
> > in order to move to a practical solution to dynamic plug-ins.
> >
> > Notice that I am saying moving to an OSGi model, not moving on top of
> > OSGi. This is not about accepting OSGi or not, for Eclipse per se,
> > the component model needs fixing to be a predictably robust platform.
> > Again, this is not an issue for deactivation, but it is an issue when
> > considering
> > dynamic loading/unloading of plug-ins. Extension management is one
aspect,
> > ensuring consistent behavior regarding class loading is another.
> >
> > PS:
> > I have tested some of the pathological cases, but I didn't want to send
> > yet another long posting... But I would be happy to describe them... :-)
> >
> > Best regards,
> > --
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> > "Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
> > news:b3vr8q$2h8$1@rogue.oti.com...
> > > Hi,
> > >
> > > As you might have guest by Jeff's message about the population of the
> CVS
> > > repo,
> > > the first problem we are interesting in tackling is the dynamic
plugins.
> > > We will start on this topic because parts of it are comitted items for
> > 2.2,
> > > however
> > > this is not restrictive and feel free to experiment on the other
fronts.
> > >
> > > This problem can be split in 4 sub-problems listed below:
> > >
> > > Plugin deactivation:
> > > Here the goal is to avoid the memory to get cluttered with unsused
> > > plugins.
> > > So the all idea here, is to unload the plugin (instances, classes,
> > > classloader)
> > > to free memory. Once a plugin has been unloaded it can still be
> > reloaded.
> > > A few problems:
> > > - how do we GC the instances,
> > > - how do we tell the other plugins a plugin get deactivated,
> > > - how do we GC the classloader,
> > > - what should be done in the shutdown methods,
> > > - is the plugin the right granularity to expose to a user to
unload
> > > - should the platform auto deactivate the plugins
> > > - ....
> > >
> > > Example: if a plugin providing menu entries is deactivated, menu
> entries
> > > are still visible.
> > >
> > >
> > > Plugin un-installation
> > > Whereas the deactivation still gives the opportunity of reactivating
a
> > > plugin,
> > > the plugin un-installation delete the plugin extensions and
extension
> > > points
> > > from the registry.
> > > A few problems:
> > > - how do we change the content of the registry (deletion)
> > > - how do we notify the other plugins about the uninstallation of
the
> > > plugin
> > > - what can plugins do when a plugin is uninstalled
> > > - ....
> > >
> > > Example: if a plugin providing menu entries is un-installed, menu
> > entries
> > > are no longer visible.
> > >
> > >
> > > Plugin installation
> > > The goal of plugin installation is the reverse of the
un-installation.
> > > A user drop a plugin into the plugins directory, and ask for a
> > "refresh",
> > > the new plugin gets discovered and its extensions and
extension-points
> > > are made visible to the other plugins.
> > > A few problems:
> > > - how do we change the content of the registry (addition)
> > > - how do we notify the other plugins about the installation of the
> > > plugin
> > > - what can plugins do when a plugin is discovered
> > > - ...
> > >
> > > Example: if the new plugin installed provides menu entries, menu
> entries
> > > are made visible.
> > >
> > >
> > > Plugin update
> > > The goal is to provide the user to update a plugin without rebooting
> the
> > > platform.
> > > One 'simple' solution is to un-install then install the same plugin,
> > > however this implies
> > > loosing some information, and useless computation.
> > >
> > >
> > > From the 4 items listed, we will start with the first one as it is
forms
> > the
> > > basis for uninstall
> > > and update.
> > >
> > > PaScaL
> > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #7734 is a reply to message #6307] |
Wed, 05 March 2003 16:05 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
So here are my manifests...
Bundle-Name: org.eclipse.core.runtime
Bundle-Name: org.eclipse.core.resources
Bundle-Name: org.eclipse.swt.win32
Bundle-Name: org.eclipse.jface
Bundle-Name: org.eclipse.jface.text
Bundle-Name: org.eclipse.ui
Bundle-Name: org.eclipse.ui.workbench
Bundle-Name: org.eclipse.ui.workbench.texteditor
These are for Eclipse 2.1.... that I had to modify a bit since
there are packages split between plug-ins... that is, two plug-ins
are contributing classes to the same package... I know it is
a temporary thing that should get fixed later... hopefully in 2.2.
Anyway, the bundle manifest might a little exporting too much...
sometimes, it was rather mechanical for me to get it to work...
but it gives a good idea... especially of the amount of dependencies
there is in terms of packages...
Notice also, there are no transitivity in OSGi... so all needed packages
need to be listed... this seems daunting but this can be fully automated
by PDE... it is really easy for PDE to see the actual import statements
in the Java source and deduce the correct and complete set of imports.
For exports... programmers have to be very disciplined... but this is very
similar to have export filters... they have to think about which packages
they want to export. A tool can easily point out missing exports for
unmatched imports...
PS:
The syntax of the manifests is a bit enhanced wrt OSGi... but nothing major,
just allowing comments, and multi-line... no biggy :-)
Best regards,
Olivier.
=====================================================
Bundle-Name: org.eclipse.core.runtime
Bundle-Version: 2.1.0
Bundle-Description: IBM OSGi LogService, LogReaderService
Bundle-Copyright: Licensed Materials - Property of IBM. (C) Copyright IBM
Corp. 2000-2002 All Rights Reserved. IBM is a registered trademark of IBM
Corp.
Bundle-Vendor: IBM Pervasive Computing
Bundle-DocUrl: http://www.ibm.com/pvc
Bundle-ContactAddress: pervasive@us.ibm.com
Build-Information: ${build-information}
Bundle-ClassPath: .,bin,src
Export-Package:
org.eclipse.core.osgi; specification-version=2.1,
org.eclipse.core.runtime; specification-version=2.1,
org.eclipse.core.runtime.model; specification-version=2.1,
org.eclipse.core.internal.plugins; specification-version=2.1
Import-Package:
org.eclipse.core.boot; specification-version=2.1,
org.apache.xerces.parsers; specification-version=1.0
Export-Service:
org.eclipse.core.osgi.IRegistryService; specification-version=2.1
Bundle-Activator:
org.eclipse.core.osgi.RuntimeActivator
=====================================================
Bundle-Name: org.eclipse.core.resources
Bundle-Description: Eclipse Core Resource Management
Bundle-Copyright: Open Source Materials - Eclipse
Bundle-Version: 2.1.0
Bundle-DocUrl: http://www.apache.org
Build-Information: ${build-information}
Bundle-ClassPath: .,bin
Import-Package:
org.eclipse.core.boot; specification-version=2.1,
org.eclipse.core.runtime; specification-version=2.1,
org.eclipse.core.runtime.model; specification-version=2.1,
org.eclipse.core.osgi; specification-version=2.1,
org.eclipse.ant.core; specification-version=2.1
Export-Package:
org.eclipse.core.resources.ant; specification-version=2.1,
org.eclipse.core.resources; specification-version=2.1,
org.eclipse.core.resources.team; specification-version=2.1
Bundle-Activator:
org.eclipse.core.osgi.PluginActivator
=====================================================
Bundle-Name: org.eclipse.swt.win32
Manifest-Version: 1.0
Bundle-Version: 2.1
Bundle-ClassPath: .,ws/win32/swt.jar,os/win32/x86
Export-Package:
org.eclipse.swt; specification-version=2.1,
org.eclipse.swt.accessibility; specification-version=2.1,
org.eclipse.swt.custom; specification-version=2.1,
org.eclipse.swt.dnd; specification-version=2.1,
org.eclipse.swt.events; specification-version=2.1,
org.eclipse.swt.graphics; specification-version=2.1,
org.eclipse.swt.layout; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1,
org.eclipse.swt.printing; specification-version=2.1,
org.eclipse.swt.program; specification-version=2.1,
org.eclipse.swt.widgets; specification-version=2.1,
org.eclipse.swt.internal; specification-version=2.1,
org.eclipse.swt.internal.win32; specification-version=2.1,
org.eclipse.swt.internal.ole.win32; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1
Bundle-NativeCode:
swt-win32-2116.dll; processor=x86; osname=Windows2000; language=en
=========================================================
Bundle-Name: org.eclipse.jface
Bundle-Description: Eclipse JFace plugin
Bundle-Copyright: Open Source Materials - Eclipse
Bundle-Version: 2.1.0
Bundle-DocUrl: http://www.apache.org
Build-Information: ${build-information}
Bundle-ClassPath: .,bin
Import-Package:
# plugin="org.apache.xerces"
javax.xml.parsers; specification-version=1.0,
org.w3c.dom; specification-version=1.0,
org.w3c.dom.events; specification-version=1.0,
org.w3c.dom.html; specification-version=1.0,
org.w3c.dom.ranges; specification-version=1.0,
org.w3c.dom.traversal; specification-version=1.0,
org.xml.sax; specification-version=1.0,
org.xml.sax.ext; specification-version=1.0,
org.xml.sax.helpers; specification-version=1.0,
org.apache.xerces.parsers; specification-version=1.0,
org.apache.xerces.dom; specification-version=1.0,
org.apache.xml.serialize; specification-version=1.0,
# plugin="org.eclipse.swt" export="true"
org.eclipse.swt; specification-version=2.1,
org.eclipse.swt.accessibility; specification-version=2.1,
org.eclipse.swt.custom; specification-version=2.1,
org.eclipse.swt.dnd; specification-version=2.1,
org.eclipse.swt.events; specification-version=2.1,
org.eclipse.swt.graphics; specification-version=2.1,
org.eclipse.swt.layout; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1,
org.eclipse.swt.printing; specification-version=2.1,
org.eclipse.swt.program; specification-version=2.1,
org.eclipse.swt.widgets; specification-version=2.1
Export-Package:
org.eclipse.jface; specification-version=2.1,
org.eclipse.jface.action; specification-version=2.1,
org.eclipse.jface.action.images; specification-version=2.1,
org.eclipse.jface.dialogs; specification-version=2.1,
org.eclipse.jface.dialogs.images; specification-version=2.1,
org.eclipse.jface.images; specification-version=2.1,
org.eclipse.jface.preference; specification-version=2.1,
org.eclipse.jface.preference.images; specification-version=2.1,
org.eclipse.jface.resource; specification-version=2.1,
org.eclipse.jface.util; specification-version=2.1,
org.eclipse.jface.viewers; specification-version=2.1,
org.eclipse.jface.window; specification-version=2.1
=====================================================
Bundle-Name: org.eclipse.jface.text
Bundle-Description: Eclipse JFace Text Support
Bundle-Copyright: Open Source Materials - Eclipse
Bundle-Version: 2.1.0
Bundle-DocUrl: http://www.apache.org
Build-Information: ${build-information}
Bundle-ClassPath: .,bin
Import-Package:
# plugin="org.eclipse.text", now part of org.eclipse.jface.text
org.eclipse.jface.text; specification-version=2.1,
# plugin="org.eclipse.jface"
org.eclipse.jface; specification-version=2.1,
org.eclipse.jface.action; specification-version=2.1,
org.eclipse.jface.action.images; specification-version=2.1,
org.eclipse.jface.dialogs; specification-version=2.1,
org.eclipse.jface.dialogs.images; specification-version=2.1,
org.eclipse.jface.images; specification-version=2.1,
org.eclipse.jface.preference; specification-version=2.1,
org.eclipse.jface.preference.images; specification-version=2.1,
org.eclipse.jface.resource; specification-version=2.1,
org.eclipse.jface.util; specification-version=2.1,
org.eclipse.jface.viewers; specification-version=2.1,
org.eclipse.jface.window; specification-version=2.1,
# plugin="org.eclipse.swt"
org.eclipse.swt; specification-version=2.1,
org.eclipse.swt.accessibility; specification-version=2.1,
org.eclipse.swt.custom; specification-version=2.1,
org.eclipse.swt.dnd; specification-version=2.1,
org.eclipse.swt.events; specification-version=2.1,
org.eclipse.swt.graphics; specification-version=2.1,
org.eclipse.swt.layout; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1,
org.eclipse.swt.printing; specification-version=2.1,
org.eclipse.swt.program; specification-version=2.1,
org.eclipse.swt.widgets; specification-version=2.1,
org.eclipse.swt.internal; specification-version=2.1,
org.eclipse.swt.internal.win32; specification-version=2.1,
org.eclipse.swt.internal.ole.win32; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1
Export-Package:
org.eclipse.jface.text; specification-version=2.1,
org.eclipse.jface.text.contentassist; specification-version=2.1,
org.eclipse.jface.text.formatter; specification-version=2.1,
org.eclipse.jface.text.information; specification-version=2.1,
org.eclipse.jface.text.presentation; specification-version=2.1,
org.eclipse.jface.text.reconciler; specification-version=2.1,
org.eclipse.jface.text.rules; specification-version=2.1,
org.eclipse.jface.text.source; specification-version=2.1
Bundle-Activator:
org.eclipse.core.boot.PluginActivator
=====================================================
Bundle-Name: org.eclipse.ui
Bundle-Description: Eclipse UI Plugin
Bundle-Copyright: Open Source Materials - Eclipse
Bundle-Version: 2.1.0
Bundle-DocUrl: http://www.apache.org
Build-Information: ${build-information}
Bundle-ClassPath: .,bin
Import-Package:
org.eclipse.core.boot; specification-version=2.1,
org.eclipse.core.osgi; specification-version=2.1,
org.eclipse.core.runtime; specification-version=2.1,
org.eclipse.core.runtime.model; specification-version=2.1,
# plugin="org.apache.xerces"
javax.xml.parsers; specification-version=1.0,
org.w3c.dom; specification-version=1.0,
org.w3c.dom.events; specification-version=1.0,
org.w3c.dom.html; specification-version=1.0,
org.w3c.dom.ranges; specification-version=1.0,
org.w3c.dom.traversal; specification-version=1.0,
org.xml.sax; specification-version=1.0,
org.xml.sax.ext; specification-version=1.0,
org.xml.sax.helpers; specification-version=1.0,
org.apache.xerces.parsers; specification-version=1.0,
org.apache.xerces.dom; specification-version=1.0,
org.apache.xml.serialize; specification-version=1.0,
# plugin="org.eclipse.swt"
org.eclipse.swt; specification-version=2.1,
org.eclipse.swt.accessibility; specification-version=2.1,
org.eclipse.swt.custom; specification-version=2.1,
org.eclipse.swt.dnd; specification-version=2.1,
org.eclipse.swt.events; specification-version=2.1,
org.eclipse.swt.graphics; specification-version=2.1,
org.eclipse.swt.layout; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1,
org.eclipse.swt.printing; specification-version=2.1,
org.eclipse.swt.program; specification-version=2.1,
org.eclipse.swt.widgets; specification-version=2.1,
org.eclipse.swt.internal; specification-version=2.1,
org.eclipse.swt.internal.win32; specification-version=2.1,
org.eclipse.swt.internal.ole.win32; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1,
# plugin="org.eclipse.jface"
org.eclipse.jface; specification-version=2.1,
org.eclipse.jface.action; specification-version=2.1,
org.eclipse.jface.action.images; specification-version=2.1,
org.eclipse.jface.dialogs; specification-version=2.1,
org.eclipse.jface.dialogs.images; specification-version=2.1,
org.eclipse.jface.images; specification-version=2.1,
org.eclipse.jface.preference; specification-version=2.1,
org.eclipse.jface.preference.images; specification-version=2.1,
org.eclipse.jface.resource; specification-version=2.1,
org.eclipse.jface.util; specification-version=2.1,
org.eclipse.jface.viewers; specification-version=2.1,
org.eclipse.jface.window; specification-version=2.1,
# plugin="org.eclipse.jface.text"
org.eclipse.jface.text; specification-version=2.1,
# plugin="org.eclipse.core.resources"
org.eclipse.core.resources.ant; specification-version=2.0,
org.eclipse.core.resources; specification-version=2.0,
org.eclipse.core.resources.team; specification-version=2.0,
# plugin="org.eclipse.update.core"
org.eclipse.update.configuration; specification-version=2.0,
org.eclipse.update.core; specification-version=2.0,
org.eclipse.update.core.model; specification-version=2.0,
# plugin="org.eclipse.help"
org.eclipse.help; specification-version=2.1,
org.eclipse.help.standalone; specification-version=2.1,
# plugin="org.eclipse.ui.views"
org.eclipse.ui.actions; specification-version=2.1,
org.eclipse.ui.views.bookmarkexplorer; specification-version=2.1,
org.eclipse.ui.views.contentoutline; specification-version=2.1,
org.eclipse.ui.views.framelist; specification-version=2.1,
org.eclipse.ui.views.navigator; specification-version=2.1,
org.eclipse.ui.views.properties; specification-version=2.1,
org.eclipse.ui.views.tasklist; specification-version=2.1,
# plugin="org.eclipse.ui.workbench"
org.eclipse.ui; specification-version=2.1,
org.eclipse.ui.actions; specification-version=2.1,
org.eclipse.ui.dialogs; specification-version=2.1,
org.eclipse.ui.help; specification-version=2.1,
org.eclipse.ui.model; specification-version=2.1,
org.eclipse.ui.part; specification-version=2.1,
org.eclipse.ui.plugin; specification-version=2.1,
org.eclipse.ui.wizards.datatransfer; specification-version=2.1,
org.eclipse.ui.wizards.newresource; specification-version=2.1,
org.eclipse.ui.workbench.internal; specification-version=2.1,
org.eclipse.ui.workbench.internal; specification-version=2.1,
org.eclipse.ui.workbench.internal.actions; specification-version=2.1,
org.eclipse.ui.workbench.internal.actions.keybindings;
specification-version=2.1,
org.eclipse.ui.workbench.internal.dialogs; specification-version=2.1,
org.eclipse.ui.workbench.internal.editorsupport; specification-version=2.1,
org.eclipse.ui.workbench.internal.misc; specification-version=2.1,
org.eclipse.ui.workbench.internal.model; specification-version=2.1,
org.eclipse.ui.workbench.internal.registry; specification-version=2.1,
org.eclipse.ui.workbench.jface.action; specification-version=2.1,
org.eclipse.ui.workbench.jface.dialogs; specification-version=2.1,
org.eclipse.ui.workbench.jface.images; specification-version=2.1,
org.eclipse.ui.workbench.jface.operation; specification-version=2.1,
org.eclipse.ui.workbench.jface.util; specification-version=2.1,
org.eclipse.ui.workbench.jface.window; specification-version=2.1,
org.eclipse.ui.workbench.jface.wizard; specification-version=2.1,
org.eclipse.ui.workbench.jface.wizard.images; specification-version=2.1,
# jface
org.eclipse.jface; specification-version=2.1,
org.eclipse.jface.action; specification-version=2.1,
org.eclipse.jface.action.images; specification-version=2.1,
org.eclipse.jface.dialogs; specification-version=2.1,
org.eclipse.jface.dialogs.images; specification-version=2.1,
org.eclipse.jface.images; specification-version=2.1,
org.eclipse.jface.preference; specification-version=2.1,
org.eclipse.jface.preference.images; specification-version=2.1,
org.eclipse.jface.resource; specification-version=2.1,
org.eclipse.jface.util; specification-version=2.1,
org.eclipse.jface.viewers; specification-version=2.1,
org.eclipse.jface.window; specification-version=2.1,
# ui.views
org.eclipse.ui.actions; specification-version=2.1,
org.eclipse.ui.views.bookmarkexplorer; specification-version=2.1,
org.eclipse.ui.views.contentoutline; specification-version=2.1,
org.eclipse.ui.views.framelist; specification-version=2.1,
org.eclipse.ui.views.navigator; specification-version=2.1,
org.eclipse.ui.views.properties; specification-version=2.1,
org.eclipse.ui.views.tasklist; specification-version=2.1,
# plugin="org.eclipse.ui.workbench.texteditor"
org.eclipse.ui.texteditor; specification-version=2.1,
# plugin="org.eclipse.ui.editors"
org.eclipse.ui.editors.text; specification-version=2.1,
org.eclipse.ui.texteditor; specification-version=2.1
Bundle-Activator:
org.eclipse.ui.internal.WorkbenchActivator
======================================================
Bundle-Name: org.eclipse.ui.workbench
Bundle-Description: Eclipse UI Plugin
Bundle-Copyright: Open Source Materials - Eclipse
Bundle-Version: 2.1.0
Bundle-DocUrl: http://www.apache.org
Build-Information: ${build-information}
Bundle-ClassPath: .,bin,src-workbench
Import-Package:
org.eclipse.core.boot; specification-version=2.1,
org.eclipse.core.osgi; specification-version=2.1,
org.eclipse.core.runtime; specification-version=2.1,
org.eclipse.core.runtime.model; specification-version=2.1,
org.eclipse.core.internal.plugins; specification-version=2.1,
# plugin="org.apache.xerces"
javax.xml.parsers; specification-version=1.0,
org.w3c.dom; specification-version=1.0,
org.w3c.dom.events; specification-version=1.0,
org.w3c.dom.html; specification-version=1.0,
org.w3c.dom.ranges; specification-version=1.0,
org.w3c.dom.traversal; specification-version=1.0,
org.xml.sax; specification-version=1.0,
org.xml.sax.ext; specification-version=1.0,
org.xml.sax.helpers; specification-version=1.0,
org.apache.xerces.parsers; specification-version=1.0,
org.apache.xerces.dom; specification-version=1.0,
org.apache.xml.serialize; specification-version=1.0,
# plugin="org.eclipse.jface"
org.eclipse.jface; specification-version=2.1,
org.eclipse.jface.action; specification-version=2.1,
org.eclipse.jface.action.images; specification-version=2.1,
org.eclipse.jface.dialogs; specification-version=2.1,
org.eclipse.jface.dialogs.images; specification-version=2.1,
org.eclipse.jface.images; specification-version=2.1,
org.eclipse.jface.preference; specification-version=2.1,
org.eclipse.jface.preference.images; specification-version=2.1,
org.eclipse.jface.resource; specification-version=2.1,
org.eclipse.jface.util; specification-version=2.1,
org.eclipse.jface.viewers; specification-version=2.1,
org.eclipse.jface.window; specification-version=2.1,
# plugin="org.eclipse.jface.text"
org.eclipse.jface.text; specification-version=2.1,
org.eclipse.jface.text.contentassist; specification-version=2.1,
org.eclipse.jface.text.formatter; specification-version=2.1,
org.eclipse.jface.text.information; specification-version=2.1,
org.eclipse.jface.text.presentation; specification-version=2.1,
org.eclipse.jface.text.reconciler; specification-version=2.1,
org.eclipse.jface.text.rules; specification-version=2.1,
org.eclipse.jface.text.source; specification-version=2.1,
# plugin="org.eclipse.core.resources"
org.eclipse.core.resources.ant; specification-version=2.0,
org.eclipse.core.resources; specification-version=2.0,
org.eclipse.core.resources.team; specification-version=2.0,
# plugin="org.eclipse.update.core"
org.eclipse.update.configuration; specification-version=2.0,
org.eclipse.update.core; specification-version=2.0,
org.eclipse.update.core.model; specification-version=2.0,
# plugin="org.eclipse.help"
org.eclipse.help; specification-version=2.1,
org.eclipse.help.standalone; specification-version=2.1,
# SWT
org.eclipse.swt; specification-version=2.1,
org.eclipse.swt.accessibility; specification-version=2.1,
org.eclipse.swt.custom; specification-version=2.1,
org.eclipse.swt.dnd; specification-version=2.1,
org.eclipse.swt.events; specification-version=2.1,
org.eclipse.swt.graphics; specification-version=2.1,
org.eclipse.swt.layout; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1,
org.eclipse.swt.printing; specification-version=2.1,
org.eclipse.swt.program; specification-version=2.1,
org.eclipse.swt.widgets; specification-version=2.1,
org.eclipse.swt.internal; specification-version=2.1,
org.eclipse.swt.internal.win32; specification-version=2.1,
org.eclipse.swt.internal.ole.win32; specification-version=2.1,
org.eclipse.swt.ole.win32; specification-version=2.1
Export-Package:
org.eclipse.ui; specification-version=2.1,
org.eclipse.ui.actions; specification-version=2.1,
org.eclipse.ui.dialogs; specification-version=2.1,
org.eclipse.ui.help; specification-version=2.1,
org.eclipse.ui.model; specification-version=2.1,
org.eclipse.ui.part; specification-version=2.1,
org.eclipse.ui.plugin; specification-version=2.1,
org.eclipse.ui.wizards.datatransfer; specification-version=2.1,
org.eclipse.ui.wizards.newresource; specification-version=2.1,
org.eclipse.ui.workbench.internal; specification-version=2.1,
org.eclipse.ui.workbench.internal.actions; specification-version=2.1,
org.eclipse.ui.workbench.internal.actions.keybindings;
specification-version=2.1,
org.eclipse.ui.workbench.internal.dialogs; specification-version=2.1,
org.eclipse.ui.workbench.internal.editorsupport; specification-version=2.1,
org.eclipse.ui.workbench.internal.misc; specification-version=2.1,
org.eclipse.ui.workbench.internal.model; specification-version=2.1,
org.eclipse.ui.workbench.internal.registry; specification-version=2.1,
org.eclipse.ui.workbench.jface.action; specification-version=2.1,
org.eclipse.ui.workbench.jface.dialogs; specification-version=2.1,
org.eclipse.ui.workbench.jface.images; specification-version=2.1,
org.eclipse.ui.workbench.jface.operation; specification-version=2.1,
org.eclipse.ui.workbench.jface.util; specification-version=2.1,
org.eclipse.ui.workbench.jface.window; specification-version=2.1,
org.eclipse.ui.workbench.jface.wizard; specification-version=2.1,
org.eclipse.ui.workbench.jface.wizard.images; specification-version=2.1
Bundle-Activator:
org.eclipse.core.osgi.PluginActivator
=========================================================
Bundle-Name: org.eclipse.ui.workbench.texteditor
Bundle-Description: Eclipse Text Editor Plugin
Bundle-Copyright: Open Source Materials - Eclipse
Bundle-Version: 2.1.0
Bundle-DocUrl: http://www.apache.org
Build-Information: ${build-information}
Bundle-ClassPath: .,bin
Import-Package:
org.eclipse.core.boot; specification-version=2.0,
org.eclipse.core.osgi; specification-version=2.0,
org.eclipse.core.runtime; specification-version=2.0,
org.eclipse.core.runtime.model; specification-version=2.0
Export-Package:
org.eclipse.ui.texteditor; specification-version=2.1
Bundle-Activator:
org.eclipse.core.osgi.PluginActivator
=========================================================
=========================================================
=========================================================
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b438uo$kn5$1@rogue.oti.com...
> Olivier,
>
> I'm a little confused by how this would all work under the OSGi model
> (importing/exporting packages, package versioning, ...). To help me (and
> others?) understand can you provide actual bundle specifications for the
> following plugins:
> org.eclipse.core.runtime
> org.eclipse.core.resources
> org.eclipse.swt
> org.eclipse.ui.* (if you can)
>
> That should be a reasonable sampling of plugin interactions (feel free to
> include others :-). The intent here is not to put you through lots of
work
> (I suspect you already have most of this done) but rather to put hard
> concrete structure behind the story.
>
> Perhaps put it on the website and point us at it?
>
> Jeff
>
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b42uqp$ckm$1@rogue.oti.com...
> > Hi PaScal,
> >
> > In a previous posting, I talk about references on classes, instances
> > and class loaders... for the deactivation/unloading to happen...
> > There is another aspect when considering dynamic loading and
> > unloading, that does not show up with deactivation...
> > a predictable behavior of the platform which Eclispe does not have
> > today. Sorry... :-)
> >
> > Eclipse is a great platform and have done incredible in promoting
> > modular tool integration... but it is also true that the current
component
> > model is error-prone and quite unpredictable. This is both a runtime and
> > tooling statement. The flaws are related to how plug-ins are build
versus
> > executed, as well as how dependencies are expressed. The current
approach
> > results in quite unpredictable behaviors, which leads to exceptions
> related
> > to class loading or hard-to-track bugs (especially with constant
> propagation
> > at compile time).
> >
> > All those pathological cases I was able to build are based on the
> following
> > aspects of the component model:
> >
> > - dependencies are expressed on plug-ins
> > - dependencies are transitive
> > - build-time dependencies may not match the runtime dependencies
> > - versionning interacts with class visibility at runtime.
> >
> > The solution is to change the component model so that we can control
> > and predict the visibility rules, both at build and run time. The
solution
> > for all of this is to move to an OSGi model, where imports and exports
> > are on specific Java packages, with versions. In other words, I am
afraid
> > that we need to drop the current plug-in dependency scheme of Eclipse
> > in order to move to a practical solution to dynamic plug-ins.
> >
> > Notice that I am saying moving to an OSGi model, not moving on top of
> > OSGi. This is not about accepting OSGi or not, for Eclipse per se,
> > the component model needs fixing to be a predictably robust platform.
> > Again, this is not an issue for deactivation, but it is an issue when
> > considering
> > dynamic loading/unloading of plug-ins. Extension management is one
aspect,
> > ensuring consistent behavior regarding class loading is another.
> >
> > PS:
> > I have tested some of the pathological cases, but I didn't want to send
> > yet another long posting... But I would be happy to describe them... :-)
> >
> > Best regards,
> > --
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> > "Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
> > news:b3vr8q$2h8$1@rogue.oti.com...
> > > Hi,
> > >
> > > As you might have guest by Jeff's message about the population of the
> CVS
> > > repo,
> > > the first problem we are interesting in tackling is the dynamic
plugins.
> > > We will start on this topic because parts of it are comitted items for
> > 2.2,
> > > however
> > > this is not restrictive and feel free to experiment on the other
fronts.
> > >
> > > This problem can be split in 4 sub-problems listed below:
> > >
> > > Plugin deactivation:
> > > Here the goal is to avoid the memory to get cluttered with unsused
> > > plugins.
> > > So the all idea here, is to unload the plugin (instances, classes,
> > > classloader)
> > > to free memory. Once a plugin has been unloaded it can still be
> > reloaded.
> > > A few problems:
> > > - how do we GC the instances,
> > > - how do we tell the other plugins a plugin get deactivated,
> > > - how do we GC the classloader,
> > > - what should be done in the shutdown methods,
> > > - is the plugin the right granularity to expose to a user to
unload
> > > - should the platform auto deactivate the plugins
> > > - ....
> > >
> > > Example: if a plugin providing menu entries is deactivated, menu
> entries
> > > are still visible.
> > >
> > >
> > > Plugin un-installation
> > > Whereas the deactivation still gives the opportunity of reactivating
a
> > > plugin,
> > > the plugin un-installation delete the plugin extensions and
extension
> > > points
> > > from the registry.
> > > A few problems:
> > > - how do we change the content of the registry (deletion)
> > > - how do we notify the other plugins about the uninstallation of
the
> > > plugin
> > > - what can plugins do when a plugin is uninstalled
> > > - ....
> > >
> > > Example: if a plugin providing menu entries is un-installed, menu
> > entries
> > > are no longer visible.
> > >
> > >
> > > Plugin installation
> > > The goal of plugin installation is the reverse of the
un-installation.
> > > A user drop a plugin into the plugins directory, and ask for a
> > "refresh",
> > > the new plugin gets discovered and its extensions and
extension-points
> > > are made visible to the other plugins.
> > > A few problems:
> > > - how do we change the content of the registry (addition)
> > > - how do we notify the other plugins about the installation of the
> > > plugin
> > > - what can plugins do when a plugin is discovered
> > > - ...
> > >
> > > Example: if the new plugin installed provides menu entries, menu
> entries
> > > are made visible.
> > >
> > >
> > > Plugin update
> > > The goal is to provide the user to update a plugin without rebooting
> the
> > > platform.
> > > One 'simple' solution is to un-install then install the same plugin,
> > > however this implies
> > > loosing some information, and useless computation.
> > >
> > >
> > > From the 4 items listed, we will start with the first one as it is
forms
> > the
> > > basis for uninstall
> > > and update.
> > >
> > > PaScaL
> > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #7777 is a reply to message #6307] |
Wed, 05 March 2003 18:39 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Jeff,
Previous post was the manifests... but they are hard to digest... and don't
really
say why it works... so here is the explaination...
All the pathological cases that I built are based on the following issues:
- dependencies are expressed on plug-ins
- dependencies are transitive
- build-time dependencies may not match the runtime dependencies
- versionning interacts with class visibility at runtime.
I would like us to discuss the OSGi model... based on :
- dependencies are expressed as imported/exported Java packages, with
versions
- Java versions maintain backward compatibility forever
- Global name space for exported packages.
The key differences with Eclipse are the versioning model (backward
compatibility forever or within major releases), and also the global
name space for exported packages where Ecplise flows classes
along the "require" dependencies... effectively creating different name
spaces.
Let's explore one interesting middle ground... take the Eclipse
versioning and the OSGi global name space... it seems to me
that this approach allows to have a predictable behavior,
allowing the build-time visibility rules to agree with the runtime
ones. Of course, the drawback is that we loose the ability to
load different versions of a Java package, if exported.
Each bundle (plug-in) specifies its imports and exports
in terms of two lists of Java packages. The exports contribute
to one unique global name space for Java packages, used to
satisfy all imports. Within that global space, there is one and
only one version of any exported package visible at any given
moment.
Exported packages are automatically imported and imported
packages shadow exported ones. For instance, if two plug-ins P
and P' exports the same package Bar, both will see the same
package, loaded by the same loader. In other words, the system
will elect which one is exporting Bar, either P or P'. Then, both
P and P' will load **that** Bar package, thereby avoiding class
cast exceptions.
Putting versions in the picture, let's say a plug-in Q exports the
same package Bar, version 1.2. The system elects version 1.2 as
the overall Bar package... therefore, all P, P', and Q will import
the version 1.2 of Bar. The version 1.2 being compatible, all
plug-ins can satisfy their imports.
If it would be a version 2.0, that is, binary incompatible... both
P or P' could not accept that version 2.0 (they depend on 1.0),
and they would be considered unresolved and therefore disabled.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b438uo$kn5$1@rogue.oti.com...
> Olivier,
>
> I'm a little confused by how this would all work under the OSGi model
> (importing/exporting packages, package versioning, ...). To help me (and
> others?) understand can you provide actual bundle specifications for the
> following plugins:
> org.eclipse.core.runtime
> org.eclipse.core.resources
> org.eclipse.swt
> org.eclipse.ui.* (if you can)
>
> That should be a reasonable sampling of plugin interactions (feel free to
> include others :-). The intent here is not to put you through lots of
work
> (I suspect you already have most of this done) but rather to put hard
> concrete structure behind the story.
>
> Perhaps put it on the website and point us at it?
>
> Jeff
>
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b42uqp$ckm$1@rogue.oti.com...
> > Hi PaScal,
> >
> > In a previous posting, I talk about references on classes, instances
> > and class loaders... for the deactivation/unloading to happen...
> > There is another aspect when considering dynamic loading and
> > unloading, that does not show up with deactivation...
> > a predictable behavior of the platform which Eclispe does not have
> > today. Sorry... :-)
> >
> > Eclipse is a great platform and have done incredible in promoting
> > modular tool integration... but it is also true that the current
component
> > model is error-prone and quite unpredictable. This is both a runtime and
> > tooling statement. The flaws are related to how plug-ins are build
versus
> > executed, as well as how dependencies are expressed. The current
approach
> > results in quite unpredictable behaviors, which leads to exceptions
> related
> > to class loading or hard-to-track bugs (especially with constant
> propagation
> > at compile time).
> >
> > All those pathological cases I was able to build are based on the
> following
> > aspects of the component model:
> >
> > - dependencies are expressed on plug-ins
> > - dependencies are transitive
> > - build-time dependencies may not match the runtime dependencies
> > - versionning interacts with class visibility at runtime.
> >
> > The solution is to change the component model so that we can control
> > and predict the visibility rules, both at build and run time. The
solution
> > for all of this is to move to an OSGi model, where imports and exports
> > are on specific Java packages, with versions. In other words, I am
afraid
> > that we need to drop the current plug-in dependency scheme of Eclipse
> > in order to move to a practical solution to dynamic plug-ins.
> >
> > Notice that I am saying moving to an OSGi model, not moving on top of
> > OSGi. This is not about accepting OSGi or not, for Eclipse per se,
> > the component model needs fixing to be a predictably robust platform.
> > Again, this is not an issue for deactivation, but it is an issue when
> > considering
> > dynamic loading/unloading of plug-ins. Extension management is one
aspect,
> > ensuring consistent behavior regarding class loading is another.
> >
> > PS:
> > I have tested some of the pathological cases, but I didn't want to send
> > yet another long posting... But I would be happy to describe them... :-)
> >
> > Best regards,
> > --
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> > "Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
> > news:b3vr8q$2h8$1@rogue.oti.com...
> > > Hi,
> > >
> > > As you might have guest by Jeff's message about the population of the
> CVS
> > > repo,
> > > the first problem we are interesting in tackling is the dynamic
plugins.
> > > We will start on this topic because parts of it are comitted items for
> > 2.2,
> > > however
> > > this is not restrictive and feel free to experiment on the other
fronts.
> > >
> > > This problem can be split in 4 sub-problems listed below:
> > >
> > > Plugin deactivation:
> > > Here the goal is to avoid the memory to get cluttered with unsused
> > > plugins.
> > > So the all idea here, is to unload the plugin (instances, classes,
> > > classloader)
> > > to free memory. Once a plugin has been unloaded it can still be
> > reloaded.
> > > A few problems:
> > > - how do we GC the instances,
> > > - how do we tell the other plugins a plugin get deactivated,
> > > - how do we GC the classloader,
> > > - what should be done in the shutdown methods,
> > > - is the plugin the right granularity to expose to a user to
unload
> > > - should the platform auto deactivate the plugins
> > > - ....
> > >
> > > Example: if a plugin providing menu entries is deactivated, menu
> entries
> > > are still visible.
> > >
> > >
> > > Plugin un-installation
> > > Whereas the deactivation still gives the opportunity of reactivating
a
> > > plugin,
> > > the plugin un-installation delete the plugin extensions and
extension
> > > points
> > > from the registry.
> > > A few problems:
> > > - how do we change the content of the registry (deletion)
> > > - how do we notify the other plugins about the uninstallation of
the
> > > plugin
> > > - what can plugins do when a plugin is uninstalled
> > > - ....
> > >
> > > Example: if a plugin providing menu entries is un-installed, menu
> > entries
> > > are no longer visible.
> > >
> > >
> > > Plugin installation
> > > The goal of plugin installation is the reverse of the
un-installation.
> > > A user drop a plugin into the plugins directory, and ask for a
> > "refresh",
> > > the new plugin gets discovered and its extensions and
extension-points
> > > are made visible to the other plugins.
> > > A few problems:
> > > - how do we change the content of the registry (addition)
> > > - how do we notify the other plugins about the installation of the
> > > plugin
> > > - what can plugins do when a plugin is discovered
> > > - ...
> > >
> > > Example: if the new plugin installed provides menu entries, menu
> entries
> > > are made visible.
> > >
> > >
> > > Plugin update
> > > The goal is to provide the user to update a plugin without rebooting
> the
> > > platform.
> > > One 'simple' solution is to un-install then install the same plugin,
> > > however this implies
> > > loosing some information, and useless computation.
> > >
> > >
> > > From the 4 items listed, we will start with the first one as it is
forms
> > the
> > > basis for uninstall
> > > and update.
> > >
> > > PaScaL
> > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #7796 is a reply to message #6312] |
Wed, 05 March 2003 19:15 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Pascal,
Sorry, I am afraid it will be again a long posting... but the pathological
cases are tricky to present... If you are not interested in the details
of the pathological cases, read the first paragraph and the last
three ones. :-)
Here are some pathological cases I was able to build.
This is not criticize Eclipse or prove that it is not working
properly. It is to discuss the pros and cons of the Eclipse
way versus the OSGi way... One depends on a global
name space for exported packages... with only one
version loaded for all exported packages, where Eclipse
allows multiple versions to be loaded but gets in more
unpredictable runtime behaviors...
The first pathology is when a plug-in P1 requires two plug-ins
P3 and P4, exporting the same API... used in extension points.
P1 has to be build against either P3 and P4. Whichever is chosen,
one extension point will fail at runtime because it is the correct type
but loaded by the wrong class loader.
One could argue that the error comes from having the same API
exported twice, from two plug-ins, and it should be a separate plug-ins.
The very obvious solution here is to move the API in its own
plug-in... but it requires to have the ability to do this... if the two
plug-ins are coming from different providers, it may be impossible.
It seems to me that this situation is quite the typical case in Eclipse
today because plug-ins package their API with their implementation...
So it seems to suggest that plug-ins are not supposed to reuse
other plug-ins' API... in particular in the extension points they
propose. The question becomes if this impedes reusability and
modularity. OSGi seems to think so in an architecture promoting
service interfaces versus service implementation. A bundle
proposes service API and an implementation... while other bundles
proposed alternate implementations of the same service API.
Anybody has an opinion if this is a future issue for a more dynamic
Eclipse ? The drawback of the OSGi is a unique global name space...
which forbids loading different versions of a Java package...
This ability for library is certainly nice for Eclipse.
Back to our pathological cases... assuming the offending API
is put in a separate plug-in... let's say the P-API plug-in.
Two situations may occur depending on plug-in dependencies.
P1 may require P-API directly or it may only require P3 and P4,
relying on the transitive nature of the require relationship. Let
suppose that P1 requires P3 and P4... and also that P-API plug-in
is a library (does not export extensions or extension points of its
own)... so now, everything works... temporarily...
With evolution, P3 and P4 might have different version requirements
on P-API. Let's say different versions in their minor version number
(in other words, they are binary compatible). At runtime, P3 and P4
will be loaded against the correct version of the library they need,
indeed Eclipse may load multiple versions of a library.
P1 will see either one, depending on the order of its "required plug-ins"...
In all cases, again, one of the extension point will fail with a class cast
exception, although the two versions of P-API are compatible.
The class cast exception will come from having two different class
loaders.
One possible solution would be at runtime to "upgrade" both P3
and P4, that is, make the new version of P-API shared by both P3
and P4... this is possible only if neither has stated a strict dependency
on a version. This seems to suggest that the P-API would be "updated"
meaning the system would try to keep only one version of it, the most
recent one. The problem would only show up then if P3 would state limited
capabilities to handle new compatible versions.
Let's look at the case where P-API versions are not compatible...
So either P3 or P4 is no longer compatible... let's P4. So P1 has
to be recompiled... here, we need to make sure the tooling catches
that one... looking transitively in the require dependencies.
The situation gets really confusin if one adds dynamic dependencies
as things evolve. Assume for an instant that P3 did not require
P-API in an early version, but still proposes an extension point to
P1. Everything would work... P3 and P4 provides two extension points
with disjoint API, and P1 provides two extensions. Cool.
Now, a new version of P3 is installed, which is now requiring P-API
in an incompatible version. However, it requires P-API for an entirely
new extension point... but leaves the one for P1 unchanged. P3 is not
binary incompatible, so P1 should still be able to run against the new
version of P3. Indeed, P1 does not use the new extension point of P3.
Now we have a quite impredictable runtime behavior...
If P1 requires P3 before P4, either P1 or P4 code will throw a
class-related exception because P1 has been bound at runtime with the
wrong version of the PAPI. At worse, we may get no class-related
exception and just unpredictable behavior, depending on the API change.
If P1 requires P4 before P3, things will work... until a new version of
P1 starts providing extensions for the new extension point provided by
P3. No we are back to the early example... but we got there dynamically,
with different plug-ins from different providers, evolving independently.
So, to summarize, it seems to me that Eclipse has chosen the ability to
load different versions of libraries over a more predictable runtime
behavior in case of fine sharing and reuse of Java packages. It seems
that fine sharing is not the typical usage scenario. It is not the case
today
in the Eclipse plug-in that I know of. OSGi seems to have made the exact
opposite choice... where fine grain sharing of Java packages is paramount
to their service-oriented architecture... much more than being able to load
different versions.
Is that a fair statement to both Eclipse and OSGi ?
Is there a way to reconciliate the two ?
I really feel that this is one of the key issue regarding dynamic plug-ins,
the other being how plug-ins and the plug-in registry will handle
extensions and extension points appearing and disappearing as plug-ins
are loaded or unloaded.
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Pascal Rapicault" <pascal_rapicault@yahoo.fr> wrote in message
news:b43nvl$t3a$1@rogue.oti.com...
> Could you describe here or on the website, what are your pathological
cases.
> I'm very curious...
> If you could directly gives code, it would be even greater.
> If you post on the website, do not forget to post the link
>
> PaScaL
>
>
> "Olivier Gruber" <ogruber@us.ibm.com> a
|
|
|
| Re: Detailed items for dynamic plugins [message #7818 is a reply to message #7796] |
Wed, 05 March 2003 19:55 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
OSGi of course has the private packages and the Bundle-Classpath. This
model makes it relatively easy to include libraries that one does not
want to share with others. I.e. libraries can be loaded multiple times
but are not shared between bundles (exported).
The global package namespace is use for -shared- packages.
I always kind of liked that (redundant) model because it allows the
plugin/bundle developer to carry its own libraries that have exactly the
right version. This is obviously at the cost of more memory because many
plugins may carry the same libraries as others. However, I always felt
that some clever tricks could reduce the memory consumption of this
model significantly.
Kind regards,
Peter Kriens
Olivier Gruber wrote:
> Pascal,
>
> Sorry, I am afraid it will be again a long posting... but the pathological
> cases are tricky to present... If you are not interested in the details
> of the pathological cases, read the first paragraph and the last
> three ones. :-)
>
> Here are some pathological cases I was able to build.
> This is not criticize Eclipse or prove that it is not working
> properly. It is to discuss the pros and cons of the Eclipse
> way versus the OSGi way... One depends on a global
> name space for exported packages... with only one
> version loaded for all exported packages, where Eclipse
> allows multiple versions to be loaded but gets in more
> unpredictable runtime behaviors...
>
> The first pathology is when a plug-in P1 requires two plug-ins
> P3 and P4, exporting the same API... used in extension points.
> P1 has to be build against either P3 and P4. Whichever is chosen,
> one extension point will fail at runtime because it is the correct type
> but loaded by the wrong class loader.
>
> One could argue that the error comes from having the same API
> exported twice, from two plug-ins, and it should be a separate plug-ins.
> The very obvious solution here is to move the API in its own
> plug-in... but it requires to have the ability to do this... if the two
> plug-ins are coming from different providers, it may be impossible.
>
> It seems to me that this situation is quite the typical case in Eclipse
> today because plug-ins package their API with their implementation...
> So it seems to suggest that plug-ins are not supposed to reuse
> other plug-ins' API... in particular in the extension points they
> propose. The question becomes if this impedes reusability and
> modularity. OSGi seems to think so in an architecture promoting
> service interfaces versus service implementation. A bundle
> proposes service API and an implementation... while other bundles
> proposed alternate implementations of the same service API.
>
> Anybody has an opinion if this is a future issue for a more dynamic
> Eclipse ? The drawback of the OSGi is a unique global name space...
> which forbids loading different versions of a Java package...
> This ability for library is certainly nice for Eclipse.
>
> Back to our pathological cases... assuming the offending API
> is put in a separate plug-in... let's say the P-API plug-in.
> Two situations may occur depending on plug-in dependencies.
>
> P1 may require P-API directly or it may only require P3 and P4,
> relying on the transitive nature of the require relationship. Let
> suppose that P1 requires P3 and P4... and also that P-API plug-in
> is a library (does not export extensions or extension points of its
> own)... so now, everything works... temporarily...
>
> With evolution, P3 and P4 might have different version requirements
> on P-API. Let's say different versions in their minor version number
> (in other words, they are binary compatible). At runtime, P3 and P4
> will be loaded against the correct version of the library they need,
> indeed Eclipse may load multiple versions of a library.
>
> P1 will see either one, depending on the order of its "required plug-ins"...
> In all cases, again, one of the extension point will fail with a class cast
> exception, although the two versions of P-API are compatible.
> The class cast exception will come from having two different class
> loaders.
>
> One possible solution would be at runtime to "upgrade" both P3
> and P4, that is, make the new version of P-API shared by both P3
> and P4... this is possible only if neither has stated a strict dependency
> on a version. This seems to suggest that the P-API would be "updated"
> meaning the system would try to keep only one version of it, the most
> recent one. The problem would only show up then if P3 would state limited
> capabilities to handle new compatible versions.
>
> Let's look at the case where P-API versions are not compatible...
> So either P3 or P4 is no longer compatible... let's P4. So P1 has
> to be recompiled... here, we need to make sure the tooling catches
> that one... looking transitively in the require dependencies.
>
> The situation gets really confusin if one adds dynamic dependencies
> as things evolve. Assume for an instant that P3 did not require
> P-API in an early version, but still proposes an extension point to
> P1. Everything would work... P3 and P4 provides two extension points
> with disjoint API, and P1 provides two extensions. Cool.
>
> Now, a new version of P3 is installed, which is now requiring P-API
> in an incompatible version. However, it requires P-API for an entirely
> new extension point... but leaves the one for P1 unchanged. P3 is not
> binary incompatible, so P1 should still be able to run against the new
> version of P3. Indeed, P1 does not use the new extension point of P3.
> Now we have a quite impredictable runtime behavior...
>
> If P1 requires P3 before P4, either P1 or P4 code will throw a
> class-related exception because P1 has been bound at runtime with the
> wrong version of the PAPI. At worse, we may get no class-related
> exception and just unpredictable behavior, depending on the API change.
>
> If P1 requires P4 before P3, things will work... until a new version of
> P1 starts providing extensions for the new extension point provided by
> P3. No we are back to the early example... but we got there dynamically,
> with different plug-ins from different providers, evolving independently.
>
> So, to summarize, it seems to me that Eclipse has chosen the ability to
> load different versions of libraries over a more predictable runtime
> behavior in case of fine sharing and reuse of Java packages. It seems
> that fine sharing is not the typical usage scenario. It is not the case
> today
> in the Eclipse plug-in that I know of. OSGi seems to have made the exact
> opposite choice... where fine grain sharing of Java packages is paramount
> to their service-oriented architecture... much more than being able to load
> different versions.
>
> Is that a fair statement to both Eclipse and OSGi ?
> Is there a way to reconciliate the two ?
>
> I really feel that this is one of the key issue regarding dynamic plug-ins,
> the other being how plug-ins and the plug-in registry will handle
> extensions and extension points appearing and disappearing as plug-ins
> are loaded or unloaded.
>
> Best regards,
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Pascal Rapicault" <pascal_rapicault@yahoo.fr> wrote in message
> news:b43nvl$t3a$1@rogue.oti.com...
>
>>Could you describe here or on the website, what are your pathological
>>
> cases.
>
>>I'm very curious...
>>If you could directly gives code, it would be even greater.
>>If you post on the website, do not forget to post the link
>>
>> PaScaL
>>
>>
>>"Olivier Gruber" <ogruber@us.ibm.com> a écrit dans le message de news:
>>b42uqp$ckm$1@rogue.oti.com...
>>
>>>Hi PaScal,
>>>
>>>In a previous posting, I talk about references on classes, instances
>>>and class loaders... for the deactivation/unloading to happen...
>>>There is another aspect when considering dynamic loading and
>>>unloading, that does not show up with deactivation...
>>>a predictable behavior of the platform which Eclispe does not have
>>>today. Sorry... :-)
>>>
>>>Eclipse is a great platform and have done incredible in promoting
>>>modular tool integration... but it is also true that the current
>>>
> component
>
>>>model is error-prone and quite unpredictable. This is both a runtime and
>>>tooling statement. The flaws are related to how plug-ins are build
>>>
> versus
>
>>>executed, as well as how dependencies are expressed. The current
>>>
> approach
>
>>>results in quite unpredictable behaviors, which leads to exceptions
>>>
>>related
>>
>>>to class loading or hard-to-track bugs (especially with constant
>>>
>>propagation
>>
>>>at compile time).
>>>
>>>All those pathological cases I was able to build are based on the
>>>
>>following
>>
>>>aspects of the component model:
>>>
>>> - dependencies are expressed on plug-ins
>>> - dependencies are transitive
>>> - build-time dependencies may not match the runtime dependencies
>>> - versionning interacts with class visibility at runtime.
>>>
>>>The solution is to change the component model so that we can control
>>>and predict the visibility rules, both at build and run time. The
>>>
> solution
>
>>>for all of this is to move to an OSGi model, where imports and exports
>>>are on specific Java packages, with versions. In other words, I am
>>>
> afraid
>
>>>that we need to drop the current plug-in dependency scheme of Eclipse
>>>in order to move to a practical solution to dynamic plug-ins.
>>>
>>>Notice that I am saying moving to an OSGi model, not moving on top of
>>>OSGi. This is not about accepting OSGi or not, for Eclipse per se,
>>>the component model needs fixing to be a predictably robust platform.
>>>Again, this is not an issue for deactivation, but it is an issue when
>>>considering
>>>dynamic loading/unloading of plug-ins. Extension management is one
>>>
> aspect,
>
>>>ensuring consistent behavior regarding class loading is another.
>>>
>>>PS:
>>>I have tested some of the pathological cases, but I didn't want to send
>>>yet another long posting... But I would be happy to describe them... :-)
>>>
>>>Best regards,
>>>--
>>>Olivier Gruber, Ph.D.
>>>Persistent & Distributed Object Platforms and Frameworks
>>>IBM TJ Watson Research Center
>>>
>>>"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
>>>news:b3vr8q$2h8$1@rogue.oti.com...
>>>
>>>>Hi,
>>>>
>>>>As you might have guest by Jeff's message about the population of the
>>>>
>>CVS
>>
>>>>repo,
>>>>the first problem we are interesting in tackling is the dynamic
>>>>
> plugins.
>
>>>>We will start on this topic because parts of it are comitted items for
>>>>
>>>2.2,
>>>
>>>>however
>>>>this is not restrictive and feel free to experiment on the other
>>>>
> fronts.
>
>>>>This problem can be split in 4 sub-problems listed below:
>>>>
>>>>Plugin deactivation:
>>>> Here the goal is to avoid the memory to get cluttered with unsused
>>>>plugins.
>>>> So the all idea here, is to unload the plugin (instances, classes,
>>>>classloader)
>>>> to free memory. Once a plugin has been unloaded it can still be
>>>>
>>>reloaded.
>>>
>>>> A few problems:
>>>> - how do we GC the instances,
>>>> - how do we tell the other plugins a plugin get deactivated,
>>>> - how do we GC the classloader,
>>>> - what should be done in the shutdown methods,
>>>> - is the plugin the right granularity to expose to a user to
>>>>
> unload
>
>>>> - should the platform auto deactivate the plugins
>>>> - ....
>>>>
>>>> Example: if a plugin providing menu entries is deactivated, menu
>>>>
>>entries
>>
>>>>are still visible.
>>>>
>>>>
>>>>Plugin un-installation
>>>> Whereas the deactivation still gives the opportunity of reactivating
>>>>
> a
>
>>>>plugin,
>>>> the plugin un-installation delete the plugin extensions and
>>>>
> extension
>
>>>>points
>>>> from the registry.
>>>> A few problems:
>>>> - how do we change the content of the registry (deletion)
>>>> - how do we notify the other plugins about the uninstallation of
>>>>
> the
>
>>>>plugin
>>>> - what can plugins do when a plugin is uninstalled
>>>> - ....
>>>>
>>>> Example: if a plugin providing menu entries is un-installed, menu
>>>>
>>>entries
>>>
>>>>are no longer visible.
>>>>
>>>>
>>>>Plugin installation
>>>> The goal of plugin installation is the reverse of the
>>>>
> un-installation.
>
>>>> A user drop a plugin into the plugins directory, and ask for a
>>>>
>>>"refresh",
>>>
>>>> the new plugin gets discovered and its extensions and
>>>>
> extension-points
>
>>>> are made visible to the other plugins.
>>>> A few problems:
>>>> - how do we change the content of the registry (addition)
>>>> - how do we notify the other plugins about the installation of the
>>>>plugin
>>>> - what can plugins do when a plugin is discovered
>>>> - ...
>>>>
>>>> Example: if the new plugin installed provides menu entries, menu
>>>>
>>entries
>>
>>>>are made visible.
>>>>
>>>>
>>>>Plugin update
>>>> The goal is to provide the user to update a plugin without rebooting
>>>>
>>the
>>
>>>>platform.
>>>> One 'simple' solution is to un-install then install the same plugin,
>>>>however this implies
>>>> loosing some information, and useless computation.
>>>>
>>>>
>>>>From the 4 items listed, we will start with the first one as it is
>>>>
> forms
>
>>>the
>>>
>>>>basis for uninstall
>>>>and update.
>>>>
>>>> PaScaL
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #7882 is a reply to message #7818] |
Wed, 05 March 2003 22:26 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
One of the scenarios we encountered in Eclipse was independent subsystems
needing different versions of the same classes. Note that this is not
limited to the so-called "library plugins". Basically product A consists of
5 plugins, product B has 3. In both A and B there is a plugin which
contains a JDBC jar (that is there are two jdbc.jars). Within the context
of A several of the 5 plugins need classes from this jar. Similarly in B.
So the jdbc.jar must be exported in both A and B. Since A and B have
nothing to do with each other, the classes in jdbc.jar should be kept
separate and their versions should not be intertwined.
Summary: Just because something is exported, does not mean it is API for
anyone to use!!
In Eclipse, the API of a plugin is defined in the doc rather than the export
list (most of the Eclipse plugins export all of their code). Other plugins
are free to use whatever they want but only the things declared as API have
any guarantees. This is akin to the JDK where rt.jar contains everything
and programmers avoid using sun.* classes.
For the record, we went down the path of exporting only our API packages and
quickly got significant pressure back from the community saying that they
needed to use non-API. It may have been that the API was not mature enough
or the usecases incomplete. Either way, the argument was, tell us what the
API is, we will try to use only API but don't restrict us.
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E665614.40709@aQute.se...
> OSGi of course has the private packages and the Bundle-Classpath. This
> model makes it relatively easy to include libraries that one does not
> want to share with others. I.e. libraries can be loaded multiple times
> but are not shared between bundles (exported).
>
> The global package namespace is use for -shared- packages.
>
> I always kind of liked that (redundant) model because it allows the
> plugin/bundle developer to carry its own libraries that have exactly the
> right version. This is obviously at the cost of more memory because many
> plugins may carry the same libraries as others. However, I always felt
> that some clever tricks could reduce the memory consumption of this
> model significantly.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> Olivier Gruber wrote:
>
> > Pascal,
> >
> > Sorry, I am afraid it will be again a long posting... but the
pathological
> > cases are tricky to present... If you are not interested in the details
> > of the pathological cases, read the first paragraph and the last
> > three ones. :-)
> >
> > Here are some pathological cases I was able to build.
> > This is not criticize Eclipse or prove that it is not working
> > properly. It is to discuss the pros and cons of the Eclipse
> > way versus the OSGi way... One depends on a global
> > name space for exported packages... with only one
> > version loaded for all exported packages, where Eclipse
> > allows multiple versions to be loaded but gets in more
> > unpredictable runtime behaviors...
> >
> > The first pathology is when a plug-in P1 requires two plug-ins
> > P3 and P4, exporting the same API... used in extension points.
> > P1 has to be build against either P3 and P4. Whichever is chosen,
> > one extension point will fail at runtime because it is the correct type
> > but loaded by the wrong class loader.
> >
> > One could argue that the error comes from having the same API
> > exported twice, from two plug-ins, and it should be a separate plug-ins.
> > The very obvious solution here is to move the API in its own
> > plug-in... but it requires to have the ability to do this... if the two
> > plug-ins are coming from different providers, it may be impossible.
> >
> > It seems to me that this situation is quite the typical case in Eclipse
> > today because plug-ins package their API with their implementation...
> > So it seems to suggest that plug-ins are not supposed to reuse
> > other plug-ins' API... in particular in the extension points they
> > propose. The question becomes if this impedes reusability and
> > modularity. OSGi seems to think so in an architecture promoting
> > service interfaces versus service implementation. A bundle
> > proposes service API and an implementation... while other bundles
> > proposed alternate implementations of the same service API.
> >
> > Anybody has an opinion if this is a future issue for a more dynamic
> > Eclipse ? The drawback of the OSGi is a unique global name space...
> > which forbids loading different versions of a Java package...
> > This ability for library is certainly nice for Eclipse.
> >
> > Back to our pathological cases... assuming the offending API
> > is put in a separate plug-in... let's say the P-API plug-in.
> > Two situations may occur depending on plug-in dependencies.
> >
> > P1 may require P-API directly or it may only require P3 and P4,
> > relying on the transitive nature of the require relationship. Let
> > suppose that P1 requires P3 and P4... and also that P-API plug-in
> > is a library (does not export extensions or extension points of its
> > own)... so now, everything works... temporarily...
> >
> > With evolution, P3 and P4 might have different version requirements
> > on P-API. Let's say different versions in their minor version number
> > (in other words, they are binary compatible). At runtime, P3 and P4
> > will be loaded against the correct version of the library they need,
> > indeed Eclipse may load multiple versions of a library.
> >
> > P1 will see either one, depending on the order of its "required
plug-ins"...
> > In all cases, again, one of the extension point will fail with a class
cast
> > exception, although the two versions of P-API are compatible.
> > The class cast exception will come from having two different class
> > loaders.
> >
> > One possible solution would be at runtime to "upgrade" both P3
> > and P4, that is, make the new version of P-API shared by both P3
> > and P4... this is possible only if neither has stated a strict
dependency
> > on a version. This seems to suggest that the P-API would be "updated"
> > meaning the system would try to keep only one version of it, the most
> > recent one. The problem would only show up then if P3 would state
limited
> > capabilities to handle new compatible versions.
> >
> > Let's look at the case where P-API versions are not compatible...
> > So either P3 or P4 is no longer compatible... let's P4. So P1 has
> > to be recompiled... here, we need to make sure the tooling catches
> > that one... looking transitively in the require dependencies.
> >
> > The situation gets really confusin if one adds dynamic dependencies
> > as things evolve. Assume for an instant that P3 did not require
> > P-API in an early version, but still proposes an extension point to
> > P1. Everything would work... P3 and P4 provides two extension points
> > with disjoint API, and P1 provides two extensions. Cool.
> >
> > Now, a new version of P3 is installed, which is now requiring P-API
> > in an incompatible version. However, it requires P-API for an entirely
> > new extension point... but leaves the one for P1 unchanged. P3 is not
> > binary incompatible, so P1 should still be able to run against the new
> > version of P3. Indeed, P1 does not use the new extension point of P3.
> > Now we have a quite impredictable runtime behavior...
> >
> > If P1 requires P3 before P4, either P1 or P4 code will throw a
> > class-related exception because P1 has been bound at runtime with the
> > wrong version of the PAPI. At worse, we may get no class-related
> > exception and just unpredictable behavior, depending on the API change.
> >
> > If P1 requires P4 before P3, things will work... until a new version of
> > P1 starts providing extensions for the new extension point provided by
> > P3. No we are back to the early example... but we got there dynamically,
> > with different plug-ins from different providers, evolving
independently.
> >
> > So, to summarize, it seems to me that Eclipse has chosen the ability to
> > load different versions of libraries over a more predictable runtime
> > behavior in case of fine sharing and reuse of Java packages. It seems
> > that fine sharing is not the typical usage scenario. It is not the case
> > today
> > in the Eclipse plug-in that I know of. OSGi seems to have made the exact
> > opposite choice... where fine grain sharing of Java packages is
paramount
> > to their service-oriented architecture... much more than being able to
load
> > different versions.
> >
> > Is that a fair statement to both Eclipse and OSGi ?
> > Is there a way to reconciliate the two ?
> >
> > I really feel that this is one of the key issue regarding dynamic
plug-ins,
> > the other being how plug-ins and the plug-in registry will handle
> > extensions and extension points appearing and disappearing as plug-ins
> > are loaded or unloaded.
> >
> > Best regards,
> > --
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> > "Pascal Rapicault" <pascal_rapicault@yahoo.fr> wrote in message
> > news:b43nvl$t3a$1@rogue.oti.com...
> >
> >>Could you describe here or on the website, what are your pathological
> >>
> > cases.
> >
> >>I'm very curious...
> >>If you could directly gives code, it would be even greater.
> >>If you post on the website, do not forget to post the link
> >>
> >> PaScaL
> >>
> >>
> >>"Olivier Gruber" <ogruber@us.ibm.com> a
|
|
| |
| Re: Detailed items for dynamic plugins [message #12154 is a reply to message #12142] |
Mon, 10 March 2003 18:57 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Right. The way Eclipse works now, the default is the latest. Plugins can
spec a more specific version and as a result may get something other than
the default. Conflicting version requirements result in multiple versions
of the plugin being activated (if it is a library plugin) or unsatisfied
constraints (if the plugin has extensions or extension points). There is no
way currently for someone to redefine the default. Not quite sure how that
would work out but seems worthwhile to think about.
Jeff
"David J. Orme" <daveo@asc-iseries.com> wrote in message
news:b4ig5e$7gf$1@rogue.oti.com...
> Jeff McAffer wrote:
> > One of the scenarios we encountered in Eclipse was independent
subsystems
> > needing different versions of the same classes. Note that this is not
> > limited to the so-called "library plugins".
>
> Let me suggest that this isn't an either-or problem. On the one hand,
> you have Eclipse where plug-ins depend on specific versions of other
> plug-ins. On the other hand, you have OSGi that uses a single global
> namespace. (I tend not to like the OSGi solution because it appears to
> be analagous to the Windows way of handling .dlls which has resulted in
> "dll hell", or creeping instability.)
>
> The third option is to allow a plug-in to depend on either a specific
> version of another plug-in or on the latest (or some default) version.
>
> This is analogous to the Unix way of handling shared objects, where by
> convention there is a symbolic link from a generic name (say libSWT.so)
> to the default version (for example, libSWT.so.2.2). Applications that
> just want the default version link against the generic name.
> Applications that need a specific version link against the full name
> with version number.
>
> With Eclipse, I think that there should be a settable default version
> for each plug-in that defaults to the latest version. If for some
> reason (say, you download a new unstable version of a plug-in to play
> with) you don't want the latest version to be the default version, you
> can change that to some earlier version.
>
> Dave
> --
> Dave Orme
> Advanced Systems Concepts
> http://www.swtworkbench.com
>
|
|
|
| Re: Detailed items for dynamic plugins [message #12164 is a reply to message #12154] |
Mon, 10 March 2003 19:33 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
It might be interesting to look at .NET.
Their versioning is based on GUID coupling between libraries. A special
administrative spec file can then be used to allow other GUIDs to be
declared compatible. .NET can load the same library multiple times if
necessary. Maybe someone has a working knowledge of this model?
I am not sure about multiple loading of the same library. If the library
has no side effects (e.g. XML parser) I guess it is OK. However,
with at least in the embedded world there are often side effects that
would make it very error prone.
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> Right. The way Eclipse works now, the default is the latest. Plugins can
> spec a more specific version and as a result may get something other than
> the default. Conflicting version requirements result in multiple versions
> of the plugin being activated (if it is a library plugin) or unsatisfied
> constraints (if the plugin has extensions or extension points). There is no
> way currently for someone to redefine the default. Not quite sure how that
> would work out but seems worthwhile to think about.
>
> Jeff
>
> "David J. Orme" <daveo@asc-iseries.com> wrote in message
> news:b4ig5e$7gf$1@rogue.oti.com...
>
>>Jeff McAffer wrote:
>>
>>>One of the scenarios we encountered in Eclipse was independent
>>>
> subsystems
>
>>>needing different versions of the same classes. Note that this is not
>>>limited to the so-called "library plugins".
>>>
>>Let me suggest that this isn't an either-or problem. On the one hand,
>>you have Eclipse where plug-ins depend on specific versions of other
>>plug-ins. On the other hand, you have OSGi that uses a single global
>>namespace. (I tend not to like the OSGi solution because it appears to
>>be analagous to the Windows way of handling .dlls which has resulted in
>>"dll hell", or creeping instability.)
>>
>>The third option is to allow a plug-in to depend on either a specific
>>version of another plug-in or on the latest (or some default) version.
>>
>>This is analogous to the Unix way of handling shared objects, where by
>>convention there is a symbolic link from a generic name (say libSWT.so)
>>to the default version (for example, libSWT.so.2.2). Applications that
>>just want the default version link against the generic name.
>>Applications that need a specific version link against the full name
>>with version number.
>>
>>With Eclipse, I think that there should be a settable default version
>>for each plug-in that defaults to the latest version. If for some
>>reason (say, you download a new unstable version of a plug-in to play
>>with) you don't want the latest version to be the default version, you
>>can change that to some earlier version.
>>
>>Dave
>>--
>>Dave Orme
>>Advanced Systems Concepts
>>http://www.swtworkbench.com
>>
>>
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #13153 is a reply to message #12164] |
Thu, 13 March 2003 16:18 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
See comments below.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E6CE892.9030608@aQute.se...
> It might be interesting to look at .NET.
>
> Their versioning is based on GUID coupling between libraries. A special
> administrative spec file can then be used to allow other GUIDs to be
> declared compatible. .NET can load the same library multiple times if
> necessary. Maybe someone has a working knowledge of this model?
>
> I am not sure about multiple loading of the same library. If the library
> has no side effects (e.g. XML parser) I guess it is OK. However,
> with at least in the embedded world there are often side effects that
> would make it very error prone.
That is a very good point... and not limited to the embedded world...
Many libraries have side effects through configuration files, temp files,
environment variables, etc... We already know that plugins with
extensions or extension points cannot be multiply loaded...
I am still not convinced that we are going down the right path.
But more importantly, we are missing real examples where
multiple loading is necessary... So, anyone has some ?
We need to be precise on why we need strict version
dependencies... binary incompatible versus buggy behavior
for instance. We also need to be very precise about the
transitive nature of class loading... are the plugins needing
specific libraries exporting packages from those libraries
or is a local need.
Looking forward to start discussing real cases...
Best regards,
> Kind regards,
>
> Peter Kriens
>
> Jeff McAffer wrote:
>
> > Right. The way Eclipse works now, the default is the latest. Plugins
can
> > spec a more specific version and as a result may get something other
than
> > the default. Conflicting version requirements result in multiple
versions
> > of the plugin being activated (if it is a library plugin) or unsatisfied
> > constraints (if the plugin has extensions or extension points). There
is no
> > way currently for someone to redefine the default. Not quite sure how
that
> > would work out but seems worthwhile to think about.
> >
> > Jeff
> >
> > "David J. Orme" <daveo@asc-iseries.com> wrote in message
> > news:b4ig5e$7gf$1@rogue.oti.com...
> >
> >>Jeff McAffer wrote:
> >>
> >>>One of the scenarios we encountered in Eclipse was independent
> >>>
> > subsystems
> >
> >>>needing different versions of the same classes. Note that this is not
> >>>limited to the so-called "library plugins".
> >>>
> >>Let me suggest that this isn't an either-or problem. On the one hand,
> >>you have Eclipse where plug-ins depend on specific versions of other
> >>plug-ins. On the other hand, you have OSGi that uses a single global
> >>namespace. (I tend not to like the OSGi solution because it appears to
> >>be analagous to the Windows way of handling .dlls which has resulted in
> >>"dll hell", or creeping instability.)
> >>
> >>The third option is to allow a plug-in to depend on either a specific
> >>version of another plug-in or on the latest (or some default) version.
> >>
> >>This is analogous to the Unix way of handling shared objects, where by
> >>convention there is a symbolic link from a generic name (say libSWT.so)
> >>to the default version (for example, libSWT.so.2.2). Applications that
> >>just want the default version link against the generic name.
> >>Applications that need a specific version link against the full name
> >>with version number.
> >>
> >>With Eclipse, I think that there should be a settable default version
> >>for each plug-in that defaults to the latest version. If for some
> >>reason (say, you download a new unstable version of a plug-in to play
> >>with) you don't want the latest version to be the default version, you
> >>can change that to some earlier version.
> >>
> >>Dave
> >>--
> >>Dave Orme
> >>Advanced Systems Concepts
> >>http://www.swtworkbench.com
> >>
> >>
> >
> >
>
|
|
|
| Re: Detailed items for dynamic plugins [message #13268 is a reply to message #13153] |
Fri, 14 March 2003 17:29 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
Olivier Gruber wrote:
> I am still not convinced that we are going down the right path.
> But more importantly, we are missing real examples where
> multiple loading is necessary... So, anyone has some ?
>
> We need to be precise on why we need strict version
> dependencies... binary incompatible versus buggy behavior
> for instance. We also need to be very precise about the
> transitive nature of class loading... are the plugins needing
> specific libraries exporting packages from those libraries
> or is a local need.
I think that in the context of Java that you're not dealing with binary
incompability (ABI compatibility) as much as the issue of differing sets
of bugs and incompatibilities being introduced and removed from
libraries over time. For example, let's consider applications A and B
and library X in versions X(n) and X(n+1) respectively.
Theoretically, it should be possible for both applications A and B to
work with library version X(n) and X(n+1) under the OSGi model, because
OSGi enforces API backwards compatibility across library versions.
However, in practice this does not always work. Here are a few of the
degenerate cases:
Suppose in all of these cases that application A depends on X(n) and
application B depends on features only available in X(n+1) and is
actively developed along with X(n+1).
- Suppose I'm actively developing library X(n+1). In this case, X(n+1)
is guaranteed not to be stable. In this case both applications A and B
will also be unstable on my machine. However, if application A could
still use the older version of the library, application A could remain
stable and I could use B to help debug my new version of X(n+1).
- Suppose library X(n+1) and application B are nearing completion (say
something like an Eclipse M6 build). If I am an end-user who needs
features in application B badly enough, I may tolerate a certain amount
of instability in application B in order to use it. However, if library
X(n+1) also caused application A to become unstable because of
undiscovered or unfixed bugs, then I'm in a quandry.
Formally speaking, the whole argument boils down to this (for those not
into mathematics, you can skip to the last paragraph in this section):
An application A in version A(x), depending on library X, is stable iff
X is stable and backwardly-compatible across all its versions.
We can rephrase that using mathematical induction:
Application A in version A(y) is stable iff X(0) is stable and
backwardly-compatible and X(n+1) is stable and backwardly-compatible.
(I will define "stable" here to mean that all bugs that are present are
of a non-critical nature to application A in version A(y). The defition
of "critical," of course depends largely on the application. For
example, the Space Shuttle has a very different definition of "critical"
than an accounting system or a word processor. I will define
"backwardly-compatible" to mean that zero API-breaking changes are
introduced between version X(n) and version X(n+1) in the same sense as
the Eclipse project has already defined this.)
Suppose we assert that X(0) is stable, which is probably reasonable,
even for libraries of a fairly significant size and complexity. X(0) is
also backwardly compatible by definition.
However, X(n+1) has several cases described above where it is either
unstable or lacks backward compatibility.
Therefore, no application A in version A(y) can depend on some library X
being stable and backwardly-compatible across all versions.
Note that these are not just contrived cases, but real cases that are
guaranteed to happen to anyone who is a developer, a beta tester, or an
early-adopter.
Also, as the number of versions (n) and the number of applications using
library X increases, the probability that some subset of ordinary users
who are not early adopters, beta testers, or developers will experience
this lack of stability also increases. One could make some simple
assumptions about the size of the set of applications, the size of the
set of libraries, and the average interdependence between applications
and libraries and graph this probability as n goes to infinity if one so
desired...
If I am a library developer and a significant number of applications
depend on my library, the amount of instability I could introduce as I
am developing could eventually become intolerable.
Let's consider one last example:
- Suppose library X is a library of the scale and popularity of GTK+ or
larger, has just undergone a major internal rewrite, and is now at a .0
release (2.0, 3.0, etc). It is nearly guaranteed that this release is
either unstable in some obscure way or lacks backward compatibility in
some obscure way that it will break a few applications that depend on
it. However, if these applications can be run using X(n) while the
applications that were not broken automatically take advantage of
X(n+1), then the ability to load multiple library versions can result in
the overall system being stable even though individual parts of it are not.
The last sentance there is key because it describes how to have an
overall stable system even though some parts of it are guranteed to be
unstable. I also think that this describes the main reason why Unix
systems typically remain stable for years but Windows systems tend to
become more and more brittle over time.
Best,
Dave Orme
--
Dave Orme
Advanced Systems Concepts
http://www.swtworkbench.com
|
|
|
| Re: Detailed items for dynamic plugins [message #13348 is a reply to message #13153] |
Fri, 14 March 2003 20:06 |
Mel Martinez
Messages: 44
Registered: July 2009 |
Member |
|
|
Olivier Gruber wrote:
> See comments below.
>
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E6CE892.9030608@aQute.se...
>
>>It might be interesting to look at .NET.
>>
>>Their versioning is based on GUID coupling between libraries. A special
>>administrative spec file can then be used to allow other GUIDs to be
>>declared compatible. .NET can load the same library multiple times if
>>necessary. Maybe someone has a working knowledge of this model?
>>
>>I am not sure about multiple loading of the same library. If the library
>> has no side effects (e.g. XML parser) I guess it is OK. However,
>>with at least in the embedded world there are often side effects that
>>would make it very error prone.
>
>
> That is a very good point... and not limited to the embedded world...
> Many libraries have side effects through configuration files, temp files,
> environment variables, etc... We already know that plugins with
> extensions or extension points cannot be multiply loaded...
>
> I am still not convinced that we are going down the right path.
> But more importantly, we are missing real examples where
> multiple loading is necessary... So, anyone has some ?
>
> We need to be precise on why we need strict version
> dependencies... binary incompatible versus buggy behavior
> for instance. We also need to be very precise about the
> transitive nature of class loading... are the plugins needing
> specific libraries exporting packages from those libraries
> or is a local need.
>
> Looking forward to start discussing real cases...
> Best regards,
I'll make an attempt at a use case for multiple versions:
Components A.1 and B.1 both depend on C.1
C.2 is released, adding new functionality.
B.2 is released, depending on new functionality in C.2 (i.e. uses
extended API)
A.1 unfortunately, realizes a bug when used with C.2 (perhaps in a
callback that C.1 never exercised). A.1 thus requires to NOT use C.2
and prefers C.1.
In this scenario, the true culprit is a bug in A.1 - but in another it
could also be in a bug in a C.2 method that A exercises but that B does not.
Here bug == any problem ranging from UI glitch all the way to major
security risk.
In order to use A.1 and B.2, both C.1 and C.2 must be loaded somehow.
If I'm understanding things right, the OSGi model is that A or B (or
both) might include the specific version of C that they need as private
packages with their respective bundle and that that resolves the
problem. Is that correct? If both of them export (publish?) C, only
the newer version is shared, right?
In Eclipse, if I'm understanding things, the scenario works so long as
A.1 and B.2 don't get used together by plugin 'D'. Is that right?
Cheers,
Mel (who definitely is not sure he is understanding things. :-)
|
|
|
| Re: Detailed items for dynamic plugins [message #13408 is a reply to message #13348] |
Sun, 16 March 2003 13:30 |
| Eclipse User |
|
|
|
Originally posted by: d3l3t3-heavy-n0spam.ungoverned.org
Mel Martinez wrote:
> If I'm understanding things right, the OSGi model is that A or B (or
> both) might include the specific version of C that they need as private
> packages with their respective bundle and that that resolves the
> problem. Is that correct? If both of them export (publish?) C, only
> the newer version is shared, right?
Yep, that is correct.
> In Eclipse, if I'm understanding things, the scenario works so long as
> A.1 and B.2 don't get used together by plugin 'D'. Is that right?
That's the way I understand it, but I will let someone else say for sure
on this one.
-> richard
|
|
|
| Re: Detailed items for dynamic plugins [message #13422 is a reply to message #13348] |
Sun, 16 March 2003 13:42 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
See my comments below
> Components A.1 and B.1 both depend on C.1
> C.2 is released, adding new functionality.
> B.2 is released, depending on new functionality in C.2 (i.e. uses
> extended API)
> A.1 unfortunately, realizes a bug when used with C.2 (perhaps in a
> callback that C.1 never exercised). A.1 thus requires to NOT use C.2
> and prefers C.1.
>
> In this scenario, the true culprit is a bug in A.1 - but in another it
> could also be in a bug in a C.2 method that A exercises but that B does
not.
>
> Here bug == any problem ranging from UI glitch all the way to major
> security risk.
>
> In order to use A.1 and B.2, both C.1 and C.2 must be loaded somehow.
>
> If I'm understanding things right, the OSGi model is that A or B (or
> both) might include the specific version of C that they need as private
> packages with their respective bundle and that that resolves the
> problem. Is that correct? If both of them export (publish?) C, only
> the newer version is shared, right?
For what I've read so far in Peter's and Olivier's posts, this seems to
be the answer.
> In Eclipse, if I'm understanding things, the scenario works so long as
> A.1 and B.2 don't get used together by plugin 'D'. Is that right?
It depends if the plugin D tries to put together classes (assign, cast)
that comes
from C1 and C2. This would means that A1 and B2 (exposes in their API
classes from C, and also export them in the "export" clause).
If the usage of C1 and C2 is only made internally in A1 and B2, then you
don't
have pb.
Note that in eclipse this scenario only works if Cs are pure libraries
(no extension points or extensions).
Moreover, eclipse also autorizes plugins to carry their own version of
libraries,
which seems to be similar to the OSGi model of private package.
>
> Cheers,
>
> Mel (who definitely is not sure he is understanding things. :-)
>
>
|
|
|
| Re: Detailed items for dynamic plugins [message #14037 is a reply to message #13268] |
Sun, 16 March 2003 16:05 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
David,
I agree with your analysis of implementation dependencies. However, you
do not take into account the ClassCastExceptions. For example, if A
[using X(n)] gives an org.w3c.dom.Node to B [using X(n+1)] a
ClassCastException is thrown. Instances that are shared between plugins
MUST have the same classloader for the class used in the assignment.
So, am I right to conclude that in the end it boils down to 2 cases?
- "Reused libraries". Classes in these libraries are -never- exchanged
between plugins and many (incompatible) versions can exist
simultaneously. These libraries should obviously also not have side
effects (i.e. like communication through static variables or
abstracting a physical device that needs controlled access: a web
server for example running on a fixed port).
- Shared librararies require a single name space to prevent
ClassCastException. These are libraries that are used
exchanged plugins. For example, if there would be multiple
copies from SWT in the platform, the workbench could not merge
components from different plugins.
This is the OSGi model. Reused libraries are private (look at the other
thread to see how we might make this efficient) and shared libraries
have a single namespace to prevent ClassCastExceptions being thrown.
Or do we need a model where a -set- of plugins share X(n) while another
-set- of plugins must share X(n+1)? This implies that some inter-plugin
communiction would take place through those libraries. My personal
opinion is that that is highly complicated, especially of these sets are
disjunct for different libraries. Or are there -concrete- use cases
where this is needed?
As a last point I'd like to stress zero-administration. I think the .NET
approach is extremebly flexible, but will require administration by the
end user in many cases.
Kind regards,
Peter Kriens
David J. Orme wrote:
> Olivier Gruber wrote:
>
>> I am still not convinced that we are going down the right path.
>> But more importantly, we are missing real examples where
>> multiple loading is necessary... So, anyone has some ?
>>
>> We need to be precise on why we need strict version
>> dependencies... binary incompatible versus buggy behavior
>> for instance. We also need to be very precise about the
>> transitive nature of class loading... are the plugins needing
>> specific libraries exporting packages from those libraries
>> or is a local need.
>
>
> I think that in the context of Java that you're not dealing with binary
> incompability (ABI compatibility) as much as the issue of differing sets
> of bugs and incompatibilities being introduced and removed from
> libraries over time. For example, let's consider applications A and B
> and library X in versions X(n) and X(n+1) respectively.
>
> Theoretically, it should be possible for both applications A and B to
> work with library version X(n) and X(n+1) under the OSGi model, because
> OSGi enforces API backwards compatibility across library versions.
> However, in practice this does not always work. Here are a few of the
> degenerate cases:
>
>
> Suppose in all of these cases that application A depends on X(n) and
> application B depends on features only available in X(n+1) and is
> actively developed along with X(n+1).
>
> - Suppose I'm actively developing library X(n+1). In this case, X(n+1)
> is guaranteed not to be stable. In this case both applications A and B
> will also be unstable on my machine. However, if application A could
> still use the older version of the library, application A could remain
> stable and I could use B to help debug my new version of X(n+1).
>
> - Suppose library X(n+1) and application B are nearing completion (say
> something like an Eclipse M6 build). If I am an end-user who needs
> features in application B badly enough, I may tolerate a certain amount
> of instability in application B in order to use it. However, if library
> X(n+1) also caused application A to become unstable because of
> undiscovered or unfixed bugs, then I'm in a quandry.
>
>
> Formally speaking, the whole argument boils down to this (for those not
> into mathematics, you can skip to the last paragraph in this section):
>
> An application A in version A(x), depending on library X, is stable iff
> X is stable and backwardly-compatible across all its versions.
>
> We can rephrase that using mathematical induction:
>
> Application A in version A(y) is stable iff X(0) is stable and
> backwardly-compatible and X(n+1) is stable and backwardly-compatible.
>
> (I will define "stable" here to mean that all bugs that are present are
> of a non-critical nature to application A in version A(y). The defition
> of "critical," of course depends largely on the application. For
> example, the Space Shuttle has a very different definition of "critical"
> than an accounting system or a word processor. I will define
> "backwardly-compatible" to mean that zero API-breaking changes are
> introduced between version X(n) and version X(n+1) in the same sense as
> the Eclipse project has already defined this.)
>
> Suppose we assert that X(0) is stable, which is probably reasonable,
> even for libraries of a fairly significant size and complexity. X(0) is
> also backwardly compatible by definition.
>
> However, X(n+1) has several cases described above where it is either
> unstable or lacks backward compatibility.
>
> Therefore, no application A in version A(y) can depend on some library X
> being stable and backwardly-compatible across all versions.
>
>
>
>
> Note that these are not just contrived cases, but real cases that are
> guaranteed to happen to anyone who is a developer, a beta tester, or an
> early-adopter.
>
> Also, as the number of versions (n) and the number of applications using
> library X increases, the probability that some subset of ordinary users
> who are not early adopters, beta testers, or developers will experience
> this lack of stability also increases. One could make some simple
> assumptions about the size of the set of applications, the size of the
> set of libraries, and the average interdependence between applications
> and libraries and graph this probability as n goes to infinity if one so
> desired...
>
> If I am a library developer and a significant number of applications
> depend on my library, the amount of instability I could introduce as I
> am developing could eventually become intolerable.
>
>
> Let's consider one last example:
>
> - Suppose library X is a library of the scale and popularity of GTK+ or
> larger, has just undergone a major internal rewrite, and is now at a .0
> release (2.0, 3.0, etc). It is nearly guaranteed that this release is
> either unstable in some obscure way or lacks backward compatibility in
> some obscure way that it will break a few applications that depend on
> it. However, if these applications can be run using X(n) while the
> applications that were not broken automatically take advantage of
> X(n+1), then the ability to load multiple library versions can result in
> the overall system being stable even though individual parts of it are not.
>
>
> The last sentance there is key because it describes how to have an
> overall stable system even though some parts of it are guranteed to be
> unstable. I also think that this describes the main reason why Unix
> systems typically remain stable for years but Windows systems tend to
> become more and more brittle over time.
>
>
>
> Best,
>
> Dave Orme
|
|
| |
| Re: Detailed items for dynamic plugins [message #15495 is a reply to message #15396] |
Tue, 25 March 2003 15:49 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"David J. Orme" <daveo@asc-iseries.com> wrote in message
news:b5nptp$6m1$1@rogue.oti.com...
> pkriens wrote:
> > <snip/>
> (I could easily see problem cases with trying to make the "set of
> plugin" dependency model work. Suppose my product depends on JDT
> plugins and also relies of library X along with JDT. Because JDT is
> earlier in my dependency graph, my plugin will be required to work with
> whatever version of X that JDT currently works with. This could get
> ugly and quite possibly create degenerate cases where Eclipse simply
> can't load--not good at all.)
Some clarification on this. Eclipse plugins do not automatically export
their imports. So if JDT requires X but does not re-export it, your plugin
will not get X's classes via JDT. That is, it will have to explicitly
require X. It also means that JDT's API does not expose any of X's classes.
As such, there is never a case where your plugin gets an X class and passes
it to JDT (or vice versa). Finally, that means that there will never be a
version collision (ClassCastException) if your plugin and JDT use different
versions of X.
If JDT were to re-export X then your plugin would get X via JDT and would
not have to require it so again, there is no possibility of version
collisions.
I don't mean to imply that version collisions can't happen, just that it is
not quite as easy as it seems.
Jeff
|
|
|
| Re: Detailed items for dynamic plugins [message #15711 is a reply to message #15495] |
Thu, 27 March 2003 17:59 |
David J. Orme
Messages: 291
Registered: July 2009 |
Senior Member |
|
|
Jeff McAffer wrote:
> "David J. Orme" <daveo@asc-iseries.com> wrote in message
> If JDT were to re-export X then your plugin would get X via JDT and would
> not have to require it so again, there is no possibility of version
> collisions.
In the current plugin implementation, this is true.
However, to clarify what I was saying, when plugins can require specific
versions of specific libraries, you can get conflicts that might even
prevent Eclipse from successfully loading everything. For example, JTD
could require and re-export library X in version n [or X(n)] and
something else, say, CDT could require and re-export X(n+1). Then if my
plugin imports both CDT and JDT, there's a conflict about which version
of X I get. In that case, my plugin would probably fail to load.
What is particularly bad about this scenario is that I have no control
over this. CDT could just make a decision some day to release a new
version that supports (and reexports) X(n+1), all my customers'
computers are updated via update manager, and then my plugin stops working.
However, I'm not sure how common this situation actually is. A possible
solution might be to establish a convention that an organization only
reexports libraries that it owns and that all exports from separate
plugins must be of the same version of the library. So to continue the
example, suppose JDT owns library X. Then only JDE would be allowed to
reexport it. CDT would not be allowed to do this. Then the problem is
solved because my plugin can only ever get library X from the same
source that is managing it and that source only over reexports a single
version.
Best,
Dave
--
Dave Orme
Advanced Systems Concepts
http://www.swtworkbench.com
|
|
| |
| Re: Detailed items for dynamic plugins [message #16522 is a reply to message #15711] |
Fri, 28 March 2003 14:42 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Dave,
I'm with you and the usecase you point out is in fact one of the problem
ones. Your observation at the end (re: people understanding what they
should re-export) is on the money too. If A re-exports B, A is saying that
(in effect) it "contains" B.
In your scenario, your plugin (in effect) is requiring the same
packages/classes from two different plugins. You are being forced into this
by CDT and JDT both re-exporting. So this is technically possible, and
likely will happen but is bad form on the part of the CDT and JDT people.
By re-exporting a plugin you limit your consumers' choices.
Again, I am not claiming that there are no problems or that they will never
occur. Even in this usecase here are still ways of constructing the error.
I'm just trying to clarify where/when/how the problems really come up.
Side note: IMHO, the need for requiring specific versions of plugins is
pretty rare. At most people should be using match="equivalent" which means
that 2.1.0 and 2.1.3 are interchangable and in general the latest will be
taken. These changes in service releases are by definition minor bug fixes
and are thus incremental improvements on the existing function. A more
liberal/confident plugin might use match="compatible" which means that 2.2.0
can be used in place of 2.1.3.
Using match="perfect" (or is it "exact"? I can never remember) is *very*
restrictive. It means that you can't even service your required plugin
without servicing yourself.
Jeff
"David J. Orme" <daveo@asc-iseries.com> wrote in message
news:b5ve15$3aa$1@rogue.oti.com...
> Jeff McAffer wrote:
> > "David J. Orme" <daveo@asc-iseries.com> wrote in message
> > If JDT were to re-export X then your plugin would get X via JDT and
would
> > not have to require it so again, there is no possibility of version
> > collisions.
>
> In the current plugin implementation, this is true.
>
> However, to clarify what I was saying, when plugins can require specific
> versions of specific libraries, you can get conflicts that might even
> prevent Eclipse from successfully loading everything. For example, JTD
> could require and re-export library X in version n [or X(n)] and
> something else, say, CDT could require and re-export X(n+1). Then if my
> plugin imports both CDT and JDT, there's a conflict about which version
> of X I get. In that case, my plugin would probably fail to load.
>
> What is particularly bad about this scenario is that I have no control
> over this. CDT could just make a decision some day to release a new
> version that supports (and reexports) X(n+1), all my customers'
> computers are updated via update manager, and then my plugin stops
working.
>
> However, I'm not sure how common this situation actually is. A possible
> solution might be to establish a convention that an organization only
> reexports libraries that it owns and that all exports from separate
> plugins must be of the same version of the library. So to continue the
> example, suppose JDT owns library X. Then only JDE would be allowed to
> reexport it. CDT would not be allowed to do this. Then the problem is
> solved because my plugin can only ever get library X from the same
> source that is managing it and that source only over reexports a single
> version.
>
>
> Best,
>
> Dave
> --
> Dave Orme
> Advanced Systems Concepts
> http://www.swtworkbench.com
>
|
|
|
Goto Forum:
Current Time: Fri Dec 27 05:55:12 GMT 2024
Powered by FUDForum. Page generated in 0.06023 seconds |
] 
Search
Help
Register
Login
Home
