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. IPluginManager 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. This has been a double-edged sword. One one side the extensibility of the Platform without having the modify the core increased greatly. On the other, "core" code became a second-class citizen in it’s own house. To work around this many of the "core" features had to be registered through placeholder plugins such as the “default-plugin” and "admin-plugin".
We also increasingly find ourselves running into the limitations of the Platform Plugin system. 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.
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. Versionsed Classes can be freely shared between bundles allowing for the controlled extension of the platform. The OSGI environment has built-in resilience to change at runtime for bundles installing and uninstalling.
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.
5.0 and 5.1 Enhancements preparing for OSGI
You can read about the steps taken to in 5.0 and 5.1 which set the stage for this migration here: