External plugins are implemented by code outside OWLIM's classpath and loaded through their own dedicated class loaders.
External plugins are packaged in plugin directories, grouped into one or more plugin home directories. Each plugin home directory may contain any number of plugin directories, each of which may contain any number of JAR files. A dedicated class loader is created for loading the code from each plugin directory. Each plugin should provide, in its plugin directory, all of its dependencies that cannot be expected to be provided through OWLIM's classpath.
Ideally, a single plugin directory should provide the implementation of a single plugin – this is recommended, but not enforced by the current implementation.
In order to allow plug-in developers maximum freedom, we load each external plug-in in a self-first class loader (contrary to Java's parent-first). This means that external plug-ins can use whatever dependencies they want, including such that override OWLIM's.
There is one caveat though. The Java ecosystem is full of various frameworks that do class instantiation based on reflection or custom class loaders. The plug-in developers should be aware of the class-loading in the frameworks they use (think Spring, slf4j, GATE, XML libraries, even Lucene) in order to prevent _ClassCastException_s and _LinkageError_s. Usually, the issue is that a dependency is using the current thread's context class loader, which is actually the OWLIM class loader (since webapp containers run each webapp in it's own thread pool and class loader) and this allows mixing of plug-in and core dependencies for bad.
Skip to end of metadata Go to start of metadata