Platform migration to OSGI
For some years now it’s been our desire to transition away from our limited home-grown plugin system to an industry standard modular system based-on OSGI. In 5.0 we began laying the groundwork for this transition. 5.1 sees us forge a clear migration path and rolls-out the first stages of OSGI in the Platform.
Why is this migration necessary? The answer requires a little background on the architecture of the Platform.
The Platform at one time was designed around a central service-locator backed by a singular ObjectFactory ( Spring in production ). Unfortunately this service locator didn’t support collections of objects, querying, or the ability to extend it without editing a bunch of core files. There was no clean way to drop something into the platform and have it integrate well with the system. Consequently the IPluginManager came to prominence.
PluginManager and PlatformPlugins provided a good “vehicle” for getting new features into the system. Since then the Platform has steadily moved to a more plugin-centric model. Unfortunately, the Platform Plugin system is not that sophisticated.
Classes cannot be shared between plugins, limiting the extension of the platform and hurting cohesion between plugins. As Classes cannot be shared , no new concepts can be added to the system. Calls between plugins are diffucult to perform, often relying using web services, content-generators and even reflection to work-around this limitation.
Some things can only be supplied through plugins, making core code a second-class citizen in it’s own house. To work around this many of the "core" features are registered through placeholder plugins, “default-plugin” and "admin-plugin".
OSGI is a industry-standard Modular Software framework. It's design supersedes that of a plugin architecture. Core code and extensions are built using the same modular design, Bundles, which most closely resemble the concept of Plugins. Everything is on the same footing in OSGI.
In truth the Migration to OSGI is not exchanging one plugin system to another. Rather it is moving to an architecture which does not require a Plugin system at all.
You can read about the steps taken to in 5.0 and 5.1 which set the stage for this migration here: Platform enhancements in 5.0 and 5.1