3. Creating a DTK Plugin

A DTK plugin is created and committed by following these steps:

  1. For agent plugins, create a Configuration Contract, see 15. Configuration Contract for further information about the contents of the configuration contract. For other types of plugins, skip this step.
     
  2. For agent plugins, generate a Java file from your configuration contract:

    > java -classpath $CLASSPATH com.digitalroute.devkit.tools.ContractGen \
    -d . -f MyAgentConfigContract.xml

    For other types of plugins, skip this step.
     

  3. Create the different Java files required for the type of plugin you want to create. See the chapters describing each plugin for further information.
     
  4. Compile all the Java files for your plugin into classes:

    > javac -classpath $CLASSPATH com/mycompany/myagent/*.java

    Note!

    It is strongly recommended that the Java code does not use the default package context. All classes in  must have unique names.

  5. Create a user defined *.jar file containing the classes, see the section below, Creating a User Defined Jar File.
     
  6. Create a user defined *.mzp package containing the *.jar file, see the section below, Creating a User Defined Package.
     
  7. Commit your user defined package, see the section below, Committing a User Defined Package.
     
  8. If you want to have user documentation for your agent plugin, create the documentation, wrap it into a user defined package and commit the package. See 16. Documentation for Agent Plugins for information about how to create and implement the help content.

Creating a User Defined Jar

To create a *.jar file containing the classes, use the following command syntax:

> jar cvf my_agent.jar com/mycompany/myagent/*.class

It is also possible to add resources to a jar file, just append any resource name to your "jar create" command. This allows you to, for instance, add images that your class depends on to the jar:

> jar cvf my_agent.jar com/mycompany/myagent/*.class com/mycompany/myagent/myagent_icon.svg

Creating a User Defined Package

In order to insert the *.jar file into , a package containing the jar file must first be created. A package gives the *.jar file a name and a version. The mzsh pcreate command creates a code package used for composing  packages (.mzp) in order to create additional functionality and updates. The name and version will be visible in the About window once the new package has been committed into the  system.

A package is created using the pcreate command in the mzsh Command Line Tool:

usage: pcreate <name> <version> <package-file> [-level <default level>] [-revision <revision> ] [-repository <repository> ] [-hidden] [[-level <level name>] file=<file-to-include> ... ] [-osgi <true/false>] [-exported <export-version> file=<jar file>]
ArgumentDescription

<name>

The name of the package

<version>

The version string of the package

<package-file>

The resulting package file name

[ -level <default level>]

Specifies if this software should support update to a running system. The default level can either be platform or execution. Execution implies that the component can be updated when the system is running, for example upgrading to a newer agent version.

Note!

Not all kinds of software using the development toolkit can be updated and also that a third party library being used by the software may or may not support the execution level.

[ -revision <revision>]

Used to show the revision number from which the .mzp file is built, that is from a revision management system.

[ -repository <repository>]

Used to show the repository from which the .mzp file is built, that is from a revision management system.

-hidden

Used if the .mzp file is not supposed to be visible in the system, for example in the About dialog.

[ -level <level name>] file=<file-to-include>

The level name can either be platform or execution. Each filename to be included can optionally be preceded by a level.

[ -osgi <true/false> ]

Used to indicate if the .mzp file has a separate third party java library file that is not packaged by . The default value is set to false.

Exporting 3PP Packages

It is advisable to use a Java wrapper as a proxy for exporting the packages used by your custom mzp.

Example - Using osgi and exportpackages

> mzsh username/password pcreate \
"My Agent" 1.0 my_agent.mzp -level execution \
file=my_agent.jar -level execution file=my_agent_javahelp.jar -osgi true \
-exportpackages com.digitalroute.devkit.mylib.javawrapper



[ -exportpackages <Java wrapper>]

A mandatory option when osgi is set to true. This option is used to export the Java wrapper for use by the DTK plugin.

Library Package Naming Conventions

To ensure that the library files not come into conflict with other  library packages, our recommended suggestion would be to apply a certain prefix to the filename of your package.

Example - Usage of exportpackages

A Java wrapper is used to call the actual third party library packages used by the mzp. The example below shows how a Java wrapper can be used.

package com.digitalroute.devkit.examples.logger;

import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.LogManager;
import org.apache.log4j.Logger;
import org.apache.logging.log4j.core.LoggerContext;

public class LoggerWrapper{
    final static Logger logger = Logger.getLogger(LoggerWrapper.class);

    public void logMessageFatal(String message){
        
            LoggerContext context = (LoggerContext) LogManager.getContext(false);
         
            logger.fatal(message);
    }
}
[ -exported <export-version> file=<jar file>]

This option is used to export all Java packages that comes bundled in a third party library package. This option is especially useful when there are multiple large third party library packages that contains large quantities of packages embedded within them.

Example - Usage of exported

Here is an example on how the option can be used. The example shows how multiple hadoop libraries can be exported.

FILES="-exported 3.1.0 file=hadoop-auth-3.1.0.jar -exported 3.1.0 file=hadoop-common-3.1.0.jar -exported 3.1.0 file=hadoop-hdfs-3.1.0.jar -exported 3.1.0 file=hadoop-aws-3.1.0.jar -exported 3.1.0 file=hadoop-annotations-3.1.0.jar"

mzsh pcreate "Apache Hadoop" "8.1.2.0" apache_hadoop_cdh4.mzp -level platform -osgi true $FILES

Committing a User Defined Package

For On-Premise, Non-Containerized environment:

New or updated code is inserted into the system using the mzsh Command Line Tool:

> mzsh username/password pcommit my_agent.mzp

For Containerized Environment (AWS or private container):

Before committing any user defined packages, your containerized environment needs to have been configured so that the /opt/mz/codeserver-dtk folder is mounted to a persistent storage.

An example configuration for this is provided. Look for the lines "# uncomment in order to load development toolkits from persistent storage" in the following config files:

  • mzhome-pvc.yaml
  • platform-statefulset.yaml

Example of configs can be download from /wiki/spaces/BUG/pages/4001988.

This is a one time configuration. Once done, any user defined package can be committed as per the instructions below.


Transfer the file to the kubernetes container and restart the pod.

> kubectl cp my_agent.mzp delivery/platform-0:/opt/mz/codeserver-dtk/packages/active
> kubectl delete pod platform-0


Note!

The name (My Agent from the example above, Creating a User Defined Package) is the package key. Thus, if a new package with the same name is inserted, then the old code for that package name is replaced.