7.1 Overview

A plug-in typically provides all the management functionality that a particular product, or feature set within a product, requires. It is assembled as a single file so you can quickly and easily add extend iManager to support the required management functionality.

However, sometimes it makes sense to bundle multiple plug-ins together, as Novell does for Novell® eDirectory™ and Novell Identity Manager™. Plug-in bundling might make sense in the following situations:

You can create plug-in files using the Jar program included in the JDK. Access and manipulate the resulting .jar files using any tool that supports the ZIP archive format.

The following sections explain concepts related to plug-ins:

7.1.1 Plug-In File Structure

A plug-in is a Java archive (JAR) file named with an .npm extension. Like all JAR files, a plug-in combines multiple files into one file and stores the relative path of each included file. The combination of the file names and the path information form a directory hierarchy. iManager imposes a directory hierarchy by requiring that some categories of files be placed within specific directories in the plug-in.

Most of the files that you would typically include in a plug-in, such as Java class files, JSPs, registration files, resources, and a manifest file, must be organized into special directories according to the file type or function. These directories are described in the following table:

Table 7-1 Plug-in directories

File or Directory

Description

currentwebapp

Contains files that are installed as part of the overall iManager Web application. These files are copied to the webapps directory of the servlet container. For example, tomcat/webapps/nps.

META-INF

(Required) Contains the required manifest file (MANIFEST.MF) with configuration information about the plug-in.

IMPORTANT:The case of the directory names and files is significant.

The structure of a plug-in that includes all of the special directories is represented in the following figure.

Figure 7-1 Plug-in structure showing all special directories.

Any files that do not need to be placed in one of the special directories, such as files for background services, can be included in a plug-in and organized in any way that meets your needs.

iManager 2.7.2 provides a framework for the plug-ins to extend the eDirectory schema during the plug-in installation. So, if a plug-in wants to extend the eDirectory schema during its installation, it has to follow a set of guidelines in its structure which are required by the schema extension framework.

  • Plug-in should provide the definition of the schema it wants to extend in either a .LDIF (single file) or a .SCH (single file) format.

  • The schema definition file should be placed under ModuleName.npm/currentwebapp/schema/ folder of the npm.

After the successful installation of the plug-in, if there is a schema file in the expected location, imanager extends the schema defined in the directory to which iManager is logged in during the plug-in installation.

NOTE:The above description is for Section 7.5.2, Installing a Plug-In Manually. For instructions on extending the schema during programmatic plug-in installation, see Section 7.5.1, Installing a Plug-In Programmatically.

Deleting files after Plug-in installation by using command-line files

A few iManager plug-ins bundle certain command-line files such as symboliclinks.txt and permissions.txt in the currentwebcommand directory of their .npm file. Another type of command-line file deletefiles.txt can now be bundled in the same directory which has a list of files to be deleted. Any file that is in the <iManager_tomcat>/webapps/nps folder can be deleted. So, the name of the files should be relative to the /nps folder. The files are deleted at the end of plug-in installation.

Limitations:

  • The names of only files can be specified. The file names should not contain any wild card characters such as *, ?, and so on. If a directory name is specified, it is not deleted because the directory would not be empty.

  • Sometimes on Windows, a few files are not deleted after the plug-in is installed. This is because the files are locked by iManager (tomcat). These files should be manually deleted.

7.1.2 Plug-In Directory Objects and Attributes

iManager creates a bhModule object in the directory to represent a plug-in. This object is registered with the portal object in the directory so that when a plug-in is installed, updated, or deleted, iManager can replicate the NPM file changes to all iManager servers servicing the portal object. The bhModule object can also store plug-in-specific configuration information and links to other plug-ins that are bundled with the plug-in.

In addition, other objects have attributes that link them to a plug-in.

7.1.3 Plug-in Update and Uninstallation

When a plug-in is updated, plug-ins contained in the NPM file are also updated. iManager uses the bhGadgets and bhModules attributes to identify the .npm and .npg files that correspond to each plug-in.

When a plug-in is uninstalled, all tasks within the plug-in are also uninstalled. As an option, the administrator can uninstall individual plug-ins within a plug-in bundle.

The uninstallation of a plug-in causes plug-ins in the file system to be deleted. File system dependency lists can be created during the uninstallation so that files that appear in other NPM archives are not deleted.

7.1.4 Plug-In Installers

A plug-in installer enables plug-ins to perform installation and configuration tasks during the installation of the portal. To learn how to create a plug-in installer, see Section 7.4, Creating a Plug-In Installer.