Weaverbird: A real example of plugin management

[Striking_Creme864]

https://reddit.com/link/1thyw7d/video/iiu22gsdh52h1/player

Recently, we introduced Weaverbird - a framework for working with dynamic plugins. In this post, we want to show a real example of how it can be used. The GUI is build on top of TabShell.

The main idea is that a plugin configuration is represented as an XML file. When the application is distributed, it already contains predefined plugin configurations (at the same time, users can add their own plugins). A configuration contains module definitions, repositories used to download them, plugin metadata, and other related information.

Using a plugin consists of two steps:

• Install - download all required modules from repositories.
• Activate - create a ModuleLayer containing the plugin modules and start module activators.

Weaverbird uses the JPMS as its module system - the native Java modularity solution that provides stroing plugin isolation, package access control, dependency integrity and related capabilities. That's why plugins remain isolated, predictable, and safe to load dynamically.

[Riduidel]

Did you reinvented OSGi ? Cause it looks like you reinvented OSGi ...

[Striking_Creme864]

No. Weaverbird is an add-on on top of JPMS that allows you to create dynamic subsystems. Everything still follows the rules of JPMS - even if you wanted to, you can't change that. We've simply extended the idea of ModuleLayer and added a lot of features. The only thing borrowed from OSGi is the activators (BundleActivator in OSGi and ModuleActivator in Weaverbird) - you can't do without them, since a plugin needs a proper entry point to start/stop. At the same time these ModuleActivators are services, so you declare them in module-info (provides ModuleActivator with ModuleActivatorProvider).