CridManager 2.0 - Writing a plugin

How to write a plugin for CridManager 2.0

• Extension Points
• Setup a plugin project in Eclipse

CridManager 2.0 is heavily based on providing plugins for extending it's functionality. There are some simple rules to follow so that new plugins fit in seamlessly into the CridManager architecture.

Directory

A plugin is simply a java jar file, that is contained in the plugins subdirectory of the CridManager realease. All jar files in this directory are included in the CridManager classpath by the plugin registry and can then be used. This way a plugin can utilise freely available libraries, eg. Jakarta Commons. Some of those libraries are included in the base release of CridManager 2.0.

Types of plugins

There are mainly two types of plugins: those that provide new functionality and those that provide resources, eg. internationalizaion (i18n) of another plugin. The latter will be described at Providing I18N for a plugin. The former will be described below.

Naming conventions

A plugin has to follow naming conventions so that the CridManager plugin registry can locate the class to initialise. Tha jar file has to be named after the class to initialise, using a fully qualified path name.

Examples:

de.cridmanager.filesystems.Filesystems.jar will load the class: de.cridmanager.filesystems.Filesystems

my.own.great.Plugin.jar will load the class: my.own.great.Plugin

Upper and lower case are significant.

Coupling components

The architecture of CridManager is based on loose coupling, managed by PicoContainer. We reduced the usage to Constructor Injection for a clean interface. This means, that all interfaces exposed by any component are registered with the plugin registry. When creating instances of components, PiconContainer fulfills all dependencies needed by the components.

An example: Logging is implemented as a service exposing the interface ILoggingService. Another component wants to use logging, so it declares a reference to ILoggingService in it constructor.

public class Plugin
{
  private ILoggingService ls;
  private ILogger myLogger;
  public Plugin(ILoggingService ls)
  {
    myLs = ls;
    myLogger = ls.getLogger(this.getClass());
  }
}

Cases may occur that a component wants to expose more than its own main class. Or a plugin may contain more than one component. In this case there's a mechanism to register more than the main class itself (what is done automatically by the plugin registry). Each plugin main class, that contains a special static method, will be called there with a reference to the plugin registry and may register other components. This method has the signature

public static void register(IPluginRegistry registry) {}

It may then register other classes it exposes (this example is from the services plugin):

public static void register(IPluginRegistry registry) {
  registry.registerComponent(LoggingService.class);
  registry.registerComponent(I18NService.class);
}