The self-hosting architecture needs to be revamped, for a cleaner
and more suited approach. This includes minor evolutions of the
architecture (boot, runtime, and update plugins) as well
as straightforward changes to the PDE tooling (especially the launcher).
The overall idea is ensure that Eclipse works as a plugin layer
above a standalone OSGi environment.
Today, Eclipse architecture does not encapsulate much of the internals
of the platform. First, plugins dive down in Boot plugin, reaching for
static methods for various information and support. Second, the Boot
plugin also provides some support to posting Runnable, and thereby
provide a single-point of management for handling exceptions. Third,
Boot provides a URL framework, as an internal package but that is used
throughout Eclipse. Fourth, Boot also contains specific support for
a PlatformConfiguration without encapsulating properly the plugin
store internals.
Bundle Store Encapsulation
OSGi advocates a strong encapsulation of the bundle store, regarding
both code and data. This is not only for security reasons but also
to hide internal implementation details, helping for portability of
applications. This impacts the overall API to the Eclipse platform.
This requires a clean API to access bundle contents. It probably needs
to work hand-in-hand with the URL framework, which needs to be moved
to the OSGi URL framework as specified in OSGi, release 3.0.
Also, since bundle contents may be large, we need to introduce a visitor
pattern in the API for accessing bundle contents.
Cleaning-up Boot
The overall Boot support has
to be cleaned up and moved as an OSGi service: reaching to static
methods in the Boot plugin is not an acceptable approach anymore.
Also, the implementation has to be cleaned up of redundancies.
There is right now two mechanisms for many things such as logging,
debug facilities, or tracing facilities. It would be nice to have
a clean merged approach.
Another issue is the support in Boot for runnable and exception
handling. Again, this needs to be surfaced as an OSGi service.
This is tightly related to issue of batching processing and the
overall multi-threading architecture.
Also, we need to integrate the persistent storage for bundles/plugins.
We also have two mechanisms there (meta-area and bundle data). This is
clearly not something to decide by PDE. This suggests to have clean
notion of target instances, with their own storage for the bundles,
plugins, metaarea, and other metadata.
Update Manager
The overall idea is to have OSGi encapsulate the code and data store—
no more direct plugin drop-in. A host Eclipse would manage target OSGi
environments and use a push-down approach to deploy bundles. In other words,
PDE launcher would trigger a push on the update manager of the specified
OSGi target. This approach supports persistent configurations, allowing
to debug the life-cycle code for plugins (startup and shutdown).
It also leverages the hot install and update capabilities in the target,
avoiding to rely solely on the hot-class-updates in the JVM.
This suggests to revisit PlatformConfiguration in Boot. In particular,
there is no reason to maintain in Boot a concept of features and
sites, which are not known to the rest of the runtime platform.
Detailed Self-Hosting Items
Prioritized list of items to work on. P1 is immediate priority,
it is a problem to fix or a missing functionality.
P2 priority is a bit more relax, it is important but not critical
for moving Equinox forward. P3 priority is about would-be-nice items.
- [P1] Move Boot URL framework to OSGi URL framework.
- [P1] Introducing API to access bundle contents (RFP-44-4.1.4)
- Based on URLs and visitors? Need incremental discovery as some bundles have huge trees.
- Can we reuse some parts of the resource plugin API?
- Hide file system classes ?
- Contents read only? If not, dangerous self hosting !!!
- If not read-only, do we need to generate change deltas.
[P2] Fix how Eclipse is started, PDE self-hosting, allowing for persistent configuration
- command line arguments
- role of Eclipse applications
- splash screen
- prechecks
- remove PlaformConfiguration
- adapt Eclipse update manager and the dependencies on it.
- merge metaarea and bundle private storage
- leverage OSGi configuration and preference management
[P2] Update manager
Adapt current update manager to the presence of bundles. Adapt features also.
Define relationship between features and scopes.
- Move update manager to OSGi level (robustness and usability)
- No more direct knowledge of the on-disk format. Use an API to install bunbles.
- Attempt to remove dependencies on the update manager through the UI.
- Cleanup/remove PlatformConfiguration from Boot plugin
- Ensure update manager can handle legacy plugins (see Backward compatibility story)
- Revisit overall product install from InstallShields and how it will leverage the
update manager: no more direct plugin drop-in.
[P3] Cleanup redundancy for debug, tracing, logging.
[P3] Cleanup Boot, move all static support to an OSGi service.
[P3] Enhancing PDE tooling
- Generating bundle manifests (import/exports, bundle identity, etc.)
- How do we generate the buildpath in terms of bundles/plugins?
- Better self-hosting through a push approach
Allows for hot updates
Support non-transient configuration
Host Eclipse as a local plugin site
Look to the SMF Bundle developer tooling (in WSDD) for code, examples, help,
development effort.
|
The current OSGi implementation is partial. We focused on the core
support needed to run Eclipse, that is, bundles and services.
Here is a list the functionality of the OSGi specification
that we left out.
- Plug&Play architecture
- Security
- Configuration management
- Permission administration
- User administration
- Preferences
Also, the implementation needs more work, mostly regarding a better
support of Eclipse requirements.
[P1] Activation Model
The current Eclipse "automagic" activation of plugins on classload
is problematic. It causes concurrency problems. Plugins are activated on class
load not on class initialize. Many classes are loaded due to verification efforts
rather than attempts to actually run them.
There are no standard hooks for discovering widespread class initialization.
To change this dramatically changes the programming model and many plugins
which uses static fields initialized through the Plugin activation.
Before thinking about changing this, we need to find a clean model.
Right, we hacked a support for running the current Eclipse plugins.
- We need declarative services to avoid starting bundles to register services
- Automated activation: class load and service lookup
- Unified activation between OSGi bundle start and plugin startup.
- Restart without restarting all of the bundles from last time (not the
same as transient bundles)
- Batching support, hide Thread class.
Events
Events may be costly if not batched through deltas. The events
for services as well as extensions are not batched yet. A negative
performance impact has to be confirmed first, and if confirmed,
deltas need to be introduced.
- Service events, delta per bundle
- Extension events, delta per plugin providing extension points
Introducing Scopes
The introduction of
scopes aims at providing a mechanism
for controlling sharing in complex configurations, thereby avoiding
DLL Hell. Besides the scope model itself, we need to decide really
quickly if we have multiple versions visible at a programming level.
The current prototype is inconsistent in that regard since OSGi promotes
a single-version model while Eclipse registry promotes a multi-version
model. Through scopes, multi-version is made possible and visible to the
administrator of the platform, but bundle/plugin developers do not see
multi-versions.
We believe the programming model should not expose
multi-versions.
Detailed OSGi Items
Prioritized list of items to work on. P1 is immediate priority,
it is a problem to fix or a missing functionality.
P2 priority is a bit more relax, it is important but not critical
for moving Equinox forward. P3 priority is about would-be-nice items.
- [P1] Fix Activation model across layers.
- [P1] Move to a reified design and more explicit reflection API for installing or updating bundles.
- [P1] Fragments
- Ensure standalone OSGi layer by adding fragment info to bundle manifest
- enforce no-activator, or coordinate the activation sequence
- enforce that the fragment services appear as services
from its master.
- [P1] Introducing matching criterion on imports
- [P1] Optimize cycle support in matching imports/exports
- Interning all string when parsing manifests
- Using a flag for declare/undeclare instead of actual removal
- [P1] Local optimization for electing provider, not the highest version.
- [P2] Filter packages from Base Classloader (RFP44-4.2.5)
- Filter out ClassLoader (need to extend Bundle interface)
- Filter out Thread (see activation model)
- [P2] Robustness regarding bundle reclaimation (class loader, classes, and objects).
- [P3] Relax constraints on presence of native libraries (RFP-44-4.1.6)
- [P3] Caching of resolved state on shutdown. Reloading on restart
- [P3] NLS & OS/ARCH/WIN support
|
Here is a status about the plugin registry.
The plugin manifest has not been changed to reflect those changes.
It would need changing PDE and also the parser. This needs to happen
fast. Also, the implementation of the registry was not easily ammenable
to dynamism; there are quite some modifications to do. The registry is
however a very straightforward data structure, so the real challenge is
to maintain some sort of backward compatibility.
When including security concerns and dynamism, this suggests to have a
strict interface-based API to the registry. Removing any access to any
internal of the Plugin registry. Hence probably breaking backward compatibility.
Fortunately, very few plugins shall be dependent on the internals of the
plugin registry.
Detailed Plugin Registry Items
Prioritized list of items to work on. P1 is immediate priority,
it is a problem to fix or a missing functionality.
P2 priority is a bit more relax, it is important but not critical
for moving Equinox forward. P3 priority is about would-be-nice items.
- [P1] Finish virtual installs/updates, missing full reflection API
- [P1] Programmatic adding/removal of extensions and extension points?
- [P1] Plugin Deactivation
- API for initiating plugin deactivation
- API/lifecycle notification events for broadcasting plugin deactivation
- Infrastructure for helping plugin writers manage their inter-plugin references
etc so they can clean up on deactivation of one of their prerequisites or
contributors.
- Allow for deactivation veto or for optionally staying active when a prerequisite
is deactivated
- [P2] Revisit the entire implementation, the current one is to exposed (security)
and not suited for dynamic behavior
- [P2] Add permissions to define extensions or extension points.
- [P3] Impacts of scopes on the Eclipse registry ?
- [P3] Do we still need the notion of singleton?
- [P3] Optimisation of events about extension life cycle (limiting overhead such as
redrawing in Workbench. Deltas— deltas au niveau du plugin/bundle
|