2c8 Modeling Tool is built on top of an OSGi implementation called Apache Felix. OSGi is a module framework using Java jar-files as a module deployment artifact, much in the same way Java EE uses ear-files and war-files as deployment artifacts.

A module in OSGi is called a "bundle" and that is typically what a plugin should be called. These documentation pages will use bundle, module and plugin interchangeably. It should be noted though that outside these pages, most OSGi resources will call them bundles.

Modeling Tool embeds an OSGi framework implementation, Apache Felix. This is the same framework implementation that some popular Java EE containers use internally, such as Glassfish and Payara. Eclipse, the Java IDE, also uses OSGi for its plugin mechanism but builds on the OSGi reference implementation called Equinox.

When Modeling Tool is started, it also starts the framework and installs a host of core bundles. If you have Modeling Tool installed, you can see these core bundles in your installation directory, under the directory /modules. These bundles are always present so in this sense, they are not plugins but the difference is only one of "core functionality" or "extended functionality". They are still OSGi bundles and are structured exactly like a plugin would be.

When the framework is started, a directory is created in the users local application data directory. Where this directory is located depends on the platform (Mac OSX or Windows are supported but the application can be run on Linux for development purposes). For Windows, the directory is typically C:\Users\_youruser_\AppData\Local\2conciliate\2024.1\bundlecache. Here, Apache Felix will keep the bundles that are installed into the framework.

Modeling Tool also exposes an API through OSGi, used to enable communication between bundles. This API is documented here.

Most plugins will also make use the OSGi service layer.

OSGi is an extensive framework used to modularize applications. Explaining what it is is outside the scope of this document but a quick summary will be given. To read more about OSGi, scroll down for a list of external resources.

OSGi is a framework where modules, called bundles, can be installed, started, stopped, updated and uninstalled. Each state is well-defined in the OSGi bundle lifecycle but the important thing to know when developing a plugin for Modeling Tool is that bundles are first installed and then started automatically by Modeling Tool once the plugin is recognized as a bundle. How to make Modeling Tool recognize your bundle is described below under OSGi bundle lifecycle.

OSGi creates an environment where different bundles can depend on each other, but more importantly on the packages included in the bundles. Package here refers to normal Java packages. In OSGi each bundle that needs to access classes in a specific package also needs to declare that they depend on that package and which version of the package it depends on. OSGi then sets up a localized "classpath" for each bundle, enabling multiple bundles to export a particular package of a particular version without interfering with other bundles. If multiple bundles export the same version of a given package, OSGi will pick one of the bundles as the "exporter" and then "bind" any bundles that wish to import the package of that version to the exporter's package. This means both that a running framework can have multiple versions of, say the json library jackson, and that all bundles get a single consistent classpath (where bundles don't "compete" for which version of jackson to use). This avoids some of the typical pitfalls of "dependency hell" here different jars that depend on different versions of jackson would be unable to co-exist in the same runtime.

Each bundle can also include its own dependencies without importing or exporting any packages from other bundles. This to makes the environments class handling less error-prone.

OSGi also contains a service layer, built on top of the module layer. Services are described using xml or Java annotations. Currently, Modeling Tool only supports service declarations in the form of xml. A service is a class that (typically) implements some interface. Other services can then state that they need a service of the interface and OSGi will inject the service to the requesting service. The idea is similar to most other DI frameworks, although the service declaration is different from both CDI, Spring and similar DI frameworks.

All bundles go through a life cycle where they are installed, resolved, started, updated, stopped and uninstalled. Exactly what each state means is covered in external sources but for a plugin to work in Modeling Tool, it must first be installed, its dependencies (package imports) must be resolved and then the plugin bundle must be started. All this happens automatically, if the plugin is placed in the plugin directory of Modeling Tool.

The directory location is platform dependent but on Windows it is located at C:\Users\_youruser_\AppData\Local\2conciliate\2024.1\ext, depending on your version of Modeling Tool.

Modeling Tool continuously scans this directory to see if any new bundles have arrived and installs, resolves and starts any new bundles identified (given that they can be resolved). If the bundle is removed from the directory it is automatically stopped and uninstalled. If the bundle's jar-file is replaced, it is typically updated (this depends not only on the name of the jar-file but also the last modified date and meta-data inside the jar-files manifest, in particular the bundle's name).

If a bundle cannot be resolved (because it is trying to import packages that no other bundle exports) it will not be started.

Most resources on the Internet make OSGi seem daunting and complicated. To better understand OSGi I would suggest finding a book that explains the concepts. Such links cannot be provided here since that might be taken as an attempt at advertising. Instead, the following resources could be used as starting points.

• Wikipedia has a descent article about OSGi. It explains what it does and has a few pointers about what the bundle manifest looks like.
• The specification can be found here. The specification is surprisingly easy to follow but might not be the first place to look for a primer on OSGi. Modeling Tool currently supports Release 6 of the core specification.
• OSGi Architecture may be of help too.