semper.util.installpackage which provides a framework for intsalling and uninstalling third-party modules into SEMPER. This description is about a first-cut design and prototype.
semper.util.installpackage which provides a framework for intsalling and uninstalling third-party modules into SEMPER. This description is about a first-cut design and prototype. Eventually, this design/implementation should be merged with the overall SEMPER framework for downloading and installing applications and module updates (see SEMPER activity paper 321IN010). Check the source for the
semper.util.installfor more recent versions of this document. The basic services for installation/uninstallation are provided by the
Installerclass. It also provides a menu-launchable Installer application that makes use of these services.
The "distribution" of the module must be available in a separate directory. The directory should contain:
name- name of the module (e.g.
block- SEMPER block to which the module belongs (e.g.
author- identification tag for the author of the module (e.g. ZRL; there is no standard name space for this yet)
purseClassName). In addition, a number of optional properties are supported by the standard Installer:
dlls- primary names of dynamically linkable libraries installed by the module; e.g.
CRMis the primary name for the Cryptomathic crypto library.
packagestop-level package names for package sub-trees installed by the module; e.g.
semper.payment.SET. A module is allowed to claim package names either within its own space in the SEMPER package hierarchy (e.g.
SETadapter for the
paymentblock can install any package prefixed with
semper.payment.SETor any name outside the SEMPER hierarchy.
packagesproperty was set, then there must be one directory for each package sub-tree specified, containing the classes for the package subtree (there can be sub-packages in the package). E.g. if
packageswas set to <
Digicash semper.payment.ecash> then there must be two sub-directories by the same names in the distribution. The
Digicashdirectory will be moved to
lib/java/classes/Digicashdirectory and the
semper.payment.ecashdirectory will be moved to
lib/java/classes/semper/payment/ecash. Missing directories is considered a critical failure.
dllsproperty was set, then there can be various versions of the each dll specified (one for each platform). The files are named: lib<BASENAME>.so.<OS> in the case of Unix (e.g. libCRMlib.so.aix) and <BASENAME>.windows.dll in the case of Windows (e.g. CRMlib.windows.dll). The correct file will be moved to
lib/java/dll/<OS>directory. Missing dlls is not considered a critical failure (since some dlls seem to be available/necessary only for some platforms) .
For interactive installation, the properties file must be named
The installation process consists of the following steps:
Installclass in the module (if available)
Installclass in the module (if available)
Installerwhen a module is being installed/uninstalled. As noted above, there are two types of installation hooks available.
A block can implement the
interface in a class and register the class with the
Installer will invoke the
appropriate interface methods from an object of this class whenever a
module is installed into the block. See payment block installation
hook for an example.
The module itself can avail itself of an installation hook by having a
Install which implements the
interface. The class must be available in the main package for that
module (i.e. the package named
semper.<BLOCK>.<MODULE-NAME> For example, the
installation hook for the
SET module of the
payment block must be named
ecash. It belongs to the
paymentblock. It comes with a shared library with the base name
ecash. It also has two java packages:
Digicash. Since it belongs to the
paymentblocks, it has a sub class of the
semper.payment.ecash.ecashPurse. Finally, the native ecash shared library uses the environment variable
ECASH_TMPDIRto figure out the name of the directory for temporary files. To package the ecash module for distribution, you will do the following:
Installwhich implements the
ModuleInstallHookinterface. The implementation of the
preInstallmethod can query the user for a temporary directory and submit that to the environment interaction front-end for registration.
semper.payment.ecashpackages and move them under the distribution directory with the same names
ecash.windows.dlland copy them under the distribution directory
name=ecash block=payment creator=DIC packages=Digicash semper.payment.ecash dlls=ecash purseClassName=semper.payment.ecash.ecashPurse
semper.util.install. The documentation includes an index and a tree depicting the class structure.