About modules
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 7. Module listing in the Nav tree sidebar
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.jarindicates a runtime modulemoduleName-wb.jarindicates themoduleName-ux.jarindicates a bajaux web modulemoduleName-doc.jarindicates an online help modulemoduleName-se.jarindicates 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 8. 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 9. 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
Figure 10. New module wizard
