...
To create and commit a DTK plugin:
Create the different Java files required for the type of plugin you want to create. See the chapters describing each plugin for further information.
...
Compile all the Java files for your plugin into classes:
Code Block > javac -classpath $CLASSPATH com/mycompany/myagent/*.java
...
| Note |
|---|
...
Caution! Do not use the default package context in the Java code |
...
. All classes |
...
in Usage Engine must have unique names. |
Create a user-defined *.jar file containing the classes, see
...
Create a user defined *.mzp package containing the *.jar file, see
...
Commit your user defined package, see
...
Creating a User Defined Jar
...
| Code Block |
|---|
> 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 Usage Engine, 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 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 systemthe system.
A package is created using the pcreate command in the mzsh Command Line Tool:
| Code Block |
|---|
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>] For Private Cloud, AWS or when you do not have a local installation, do: java -jar $DEVKIT_JAR pcreate ... |
...
Argument | Description |
|---|---|
| The name of the package |
| The version string of the package |
| The resulting package file name |
| Specifies if this software should support update to a running system. The default level can either be |
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. | |
| Used to show the revision number from which the |
| Used to show the repository from which the |
| Used if the |
| The level name can either be platform or execution. Each filename to be included can optionally be preceded by a level. |
|
|
|
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.
| Note | ||
|---|---|---|
| ||
It is advisable to use a Java wrapper as a proxy for exporting the packages used by your custom mzp. |
| title | Example - Using osgi and exportpackages |
|---|
| When this argument is set to true, the MZP will be built as an OSGi bundle. This ensures that the Java code within the bundle is isolated from the rest of Usage Engine. Use OSGi bundling when your DTK plugin depends on third-party libraries that you need to include in the MZP, so they do not cause any conflicts with the rest of the system. Only the Java packages explicitly exported will be visible to Usage Engine. To specify which Java packages to export, use the following options:
The default value is | ||||
| When the com.mycompany.myagent1,com.mycompany.myagent2
|
|
|
|
|
|
|
|
| ||
[ |
- |
A mandatory option when osgi is set to true. This option is used to export the Java wrapper for use by the DTK plugin.
| Note | ||
|---|---|---|
| ||
To ensure that the library files not come into conflict with other |
| title | 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.
| Code Block | ||
|---|---|---|
| ||
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 |
argument will export all Java packages |
| title | 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.
| Code Block | ||
|---|---|---|
| ||
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 |
...
contained within the specified JAR file when used with the argument
|
Committing a User Defined Package
| Code Block |
|---|
To commit a user defined package: 1. $ kubectl cp my_agent.mzp platform-0:/opt/mz 2. $ kubectl exec -it platform-0 -- bash 3. $ mzsh user/pw pcommit my_agent.mzp |
| Note |
Note!
The name (My Agent from the example above, https://infozone.atlassian.net/wiki/spaces/UEPE3D/pages/21469889/Creating+a+DTK+Plugin+3.2#Creating-a-User-Defined
...
-Jar) 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.