.. _PLUGIN:

PlugIns
=======

The D1 kernel is relatively small and consists only of the services required for local messaging. 
All other content is provided via plug-ins.

The PlugIn system is kept simple. 
However, plug-ins can still participate fully in messaging.

.. _PLUGININTERFACE:

Plug-in Interface
*****************

Plug-ins are JAR files and have a class that implements the ``IPlugIn`` interface. 
Here is an example of the class for the Monitor PlugIn::

    package de.softdevel.d1.monitor.impl;

    import java.net.URL;
    import java.net.URLClassLoader;

    import de.softdevel.d1.exception.CException;
    import de.softdevel.d1.kernel.IKernel;
    import de.softdevel.d1.plugin.IPlugIn;

    public final class CModule implements IPlugIn
    {
        private CMonitorFrame mFrame = null;

        @Override
        public void startPlugin(final URL aUrl,
                                final URLClassLoader aClassLoader,
                                final IKernel aKernel) throws CException
        {
            if (mFrame == null)
            {
                mFrame = new CMonitorFrame(aKernel);
            }
        }

    }

The class is very simple. 
As you can see, only the kernel is needed to bind the monitor to the messaging. 
Only a swing frame is created here, which accepts the kernel for the use of the messaging.

This simplicity is also the reason why we simply run programs using devel. one as a plug-in. 
PlugIns can easily be copied from one NODE to another. 
It is also easy to implement GUI programs as a plug-in. 
It is also easy to split the implementation of the user interface between different plug-ins.

.. _PLUGINMANIFEST:

Plug-in Manifest
****************

In order for the kernel to find the correct plug-in class, it must be specified in the JAR manifest.
Technically, this works with many build systems. 
We use Gradle::

    apply plugin: 'java'
    apply plugin: 'checkstyle'

    version = '1.0'

    repositories {
        jcenter()
    }

    dependencies {
        compile project(':D1Kernel')
        compile project(':D1MonitorAPIPlugIn')
        
        compile 'org.slf4j:slf4j-api:1.7.21'

        testCompile 'junit:junit:4.12'
    }

    jar {
        manifest {
            attributes(["Manifest-Version": "1.0"])
            attributes(["Implementation-Title": "D1 Monitor PlugIn"])
            attributes(["Implementation-Vendor": "softdevel GmbH, Hohenwestedt, Germany"])
            attributes(["Implementation-URL": "www.softdevel.de"])
            attributes(["Implementation-Version": version])
            attributes(["PlugIn-Class": "de.softdevel.d1.monitor.impl.CModule"], "devel.one")
        }
    }

The last line of the manifest entry is important (``PlugIn-Class``). 
The complete class name is entered here.

.. _PLUGINCONTROL:

Loading Sequence
****************

A plug-in may depend on other plug-ins. 
The order of loading is defined in the file ``plugins. txt`` in the configuration directory::

    D1NetworkPlugIn
    D1TcpPlugIn
    D1LogCatcherPlugIn
    D1MonitorAPIPlugIn
    D1MonitorPlugIn
    D1MonitorLogPlugIn
    D1MonitorSequencePlugIn
    D1TestPlugIn
    D1GateKeeperPlugIn
    D1Application
    D1PrivateOnlineTestPlugIn

Since the plug-in ``D1MonitorPlugIn`` depends on the plug-in ``D1MonitorAPIPlugIn``, the latter is loaded first.

The above plug-in control file is also useful for other reasons. 
All plug-ins of your systems can be located centrally in a directory on a file server. 
Only those plug-ins are loaded that are also entered in the control file. 
This makes it easier to work with system updates of many D1-NODES.