All (.jar) modules:
-
are composed of a single Java ARchive (JAR) file compliant with PKZIP compression
-
contain an XML manifest
-
are independently versioned and deployable
-
state their dependencies on other modules and their versions
JAR files are the mechanism for distributing Java modules. JAR stands for “Java archive.” A JAR file (.jar) is basically a compressed package whose components can be viewed with WinZip or other archive viewing tool. Do not attempt to unzip a JAR file—it will not work. JAR files are the add-ins that are plugged into the software to give additional functionality. Inside the JAR file are the compressed software; its documentation; in some cases, examples or pre-canned applications; and libraries.
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 or module is versioned independently.
Niagara’s versioning system allows you to check to make sure that you have the latest available module for your system. Versions are specified as a series of whole numbers separated by a period, for example “1.0.42”. To understand which version of a module is more recent, simply observe the module version number. For example, 2.3.42 is later than 2.3.35 because 2.3.42 > 2.3.35.
Figure 6 shows modules listed, by name, with the version number and installation status, as viewed in the Workbench software manager.
Niagara versioning uses the following set of conventions:
-
Versions are specified using a base four-part version with optional patch versions.
-
The first number specifies the specification revision. This number starts at one and is incremented each time the specification of the module is incremented. It is used with Baja modules to track the Baja specification version.
-
The next two numbers specify a major Niagara release.
-
The fourth number specifies a build number. A build number starts at zero for each major release and increments each time all the software’s modules are built.
-
Additional numbers may be specified for code changes made off a branch of a specific build. These are usually minor changes and bug fixes.
Every module has two versions. The first is the “bajaVersion” which maps the module to a Baja specification version. If the module is not published under the Baja process then this value is “0”. Secondly every module declares a “vendor” name and “vendorVersion”. The vendor name is a case insensitive identifier for the company who developed the module and the vendorVersion identifies the vendor's specific version of that module.
Tridium's vendorVersions are formatted as “major.minor.build[.patch]”:
-
Major and minor declare a feature release such as 3.8.
-
The third number specifies a build number. A build number starts at zero for each feature release and increments each time all the software modules are built.
-
Addition numbers may be specified for code changes made off a branch of a specific build. These are usually patch builds for minor changes and bug fixes.
So the vendorVersion “3.7.22” represents a module of build 22 in Niagara release 3.7. The vendorVersion “3.7.45.2” is the second patch of build 45 in release 3.7.
Every (.jar) module is managed in its own directory structure. Figure 7 shows an example of a directory for the alarm 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 will be zipped up for the module's jar file.