About modules

Modules are the smallest units of software in the framework architecture.

Major releases of the software are distributed along with a set of release modules (.jar extension), but as new modules are made available for that release, they may be distributed as independent revisions within that release. Following, is a partial list of modules, as displayed in the Nav sidebar pane.

Figure 1. Module listing in the Nav tree sidebar


Note: Don’t confuse modules with components. Components are used to build implementations, while modules make up the software itself.

Module characteristics

All modules are composed of a single Java Archive (.jar) file that complies with PKZIP compression. Modules contain an XML manifest; they state their dependencies on other modules and their versions.

About jar files

Module .jar files are the mechanism for distributing Java modules. A .jar file is basically a compressed package whose components can be viewed with PKZIP or other archive viewing tool. Do not attempt to unzip a .jar file. The extracted file will not work. Module .jar files are the add-ins that are plugged into the software to give additional functionality. Inside a JAR file are the compressed software; its documentation; in some cases, examples or pre-canned applications; and libraries.

There are different types of modules based on the applicable runtime profile (bajaux, doc, runtime):

  • moduleName-rt.jar indicates a runtime module

  • moduleName-wb.jar indicates the Workbench module

  • moduleName-ux.jar indicates a bajaux web module

  • moduleName-doc.jar indicates an online help module

  • moduleName-se.jar indicates a Java SE compact-3 compliant module

Some modules, such as the lonworks module, are distributed as multiple JAR files because there are so many different LonWorks devices. The core protocol is packaged in a JAR file called lonWorks.jar. There are individual .jar files for each LON device manufacturer (for example, lon_mfgName.jar). Every .jar file has its own version number.

About module versions

The framework uses the module version number to make sure that you have the latest available module. Versions are specified as a series of whole numbers separated by a period, for example 4.0.16. To understand which version of a module is more recent, simply observe the module version number. For example, 4.0.16 is higher (more recent) than 4.0.8 because 4.0.16 > 4.0.8.

About directory structure

Every (.jar) module is managed in its own directory structure. The image below shows an example of a directory for the platDaemon-rt module.

All of the source code that is used to build the module’s .jar file is located under the src directory. During the build process the libJar directory is used to build up the image, which is then zipped up to create the module's .jar file.
Figure 2. Directory structure used to build the module’s jar


Benefits of modular software development

Modular software development provides several benefits, including the following:

  • Improves tracking deployment and the assigning of version numbers

    For example, if a new driver is available to be added to the framework, it can be packaged, delivered, and added as a single module or with multiple modules, using the platform Software Manager view. Refer to the Niagara Platform Guide.

    Figure 3. Software manager view


  • Requires less space on the controller — the framework’s modular development saves space in your controller by installing only necessary modules.

  • Requires less space on the workstation — when you install the framework, you can choose the modules that you want to install with your application and omit any modules that you do not need. Later, you add modules using the platform Software Manager (as shown).

  • Simplifies dependencies and secures files — a .jar’s runtime profile describes its contents based on which systems are able to use them, or on which content is appropriate for its configuration. This simplifies handling of dependencies and enables files to be secured via digital signature.

  • Creates new modules — software developers can use the New Module tool in Workbench to create new (.jar) modules and deploy them.

    Figure 4. New module wizard