Developers specify various properties of a module via a module.properties file, a file of fixed property/value strings. These properties affect the behavior of the module and are shown in the Admin Console.
Build Module with module.properties
In the module source code, this file is located in the module root at MODULE_ROOT/module.properties.
helloWorldModule
│ module.properties
└───resources
├───...
├───...
└───...
When you run the standard targets to build LabKey Server, the property/value pairs in module.properties are extracted and used to populate a config/module.xml file into module.template.xml via string substitution. The resulting config/module.xml file is copied to the module's config subdirectory (MODULE_NAME/config/module.xml) and finally packaged into the built .module file. At deployment time, the server loads properties from config/module.xml, not module.properties, which the server ignores. Note that modules that contain Java code must be built using the standard build targets in the open source project. This generated module.xml file is not be be confused with the module.xml file described
here.
module.properties Examples
The following module.properties file is for a simple file-based module which contains no Java classes to compile:
Name: HelloWorld
ModuleClass: org.labkey.api.module.SimpleModule
Modules that contain Java classes should reference their main Java class. For example, the Core module references the main controller class org.labkey.core.CoreModule:
Name: Core
ModuleClass: org.labkey.core.CoreModule
SchemaVersion: 20.001
Label: Administration and Essential Services
Description: The Core module provides central services such as login,
security, administration, folder management, user management,
module upgrade, file attachments, analytics, and portal page management.
Organization: LabKey
OrganizationURL: https://www.labkey.com/
License: Apache 2.0
LicenseURL: http://www.apache.org/licenses/LICENSE-2.0
module.properties Reference
Available properties for module.properties.
| Property Name | Description |
|---|
| BuildNumber | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The build number. |
| BuildOS | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The operating system upon which the module was built. This will be displayed next to the module in the site admin console. |
| BuildPath | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The file path in which the module was built. This will be displayed next to the module in the site admin console. |
| BuildTime | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The date and time the module was built. This will be displayed next to the module in the site admin console. |
| BuildType | Possible values are "Development" or "Production". "Development" modules will not deploy on a production machine. To build modules destined for a production server, run 'gradlew deployApp -PdeployMode=prod' in the root of your enlistment, or add the following to the module.properties file: 'BuildType=Production'. |
| BuildUser | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The name of the user that built the module; teamcity-agent for pre-built artifacts. |
| Description | Multi-line description of module. |
| EnlistmentId | This value is set internally by the build, and does not need to be provided by the developer in module.properties. Used to determine whether the module was built on the current server. |
| Label | One line description of module's purpose (display capitalized and without a period at the end). |
| License | License name: e.g. "Apache 2.0", "LabKey Software License", etc. |
| LicenseURL | License URL: e.g. "http://www.apache.org/licenses/LICENSE-2.0" |
| Maintainer | Comma separated list of names and, optionally, email addresses: e.g. "Adam Smith <adams@someemail.com>, Kevin Kroy" |
| ModuleClass | Main class for the module. For modules without Java code, use org.labkey.api.module.SimpleModule |
| Name | The display name for the module. |
| Organization | The organization responsible for the module. |
| OrganizationURL | The organization's URL/homepage. |
| RequiredServerVersionooo | The minimum required version for LabKey Server. |
| ResourcePath | This value is set internally by the build, and does not need to be provided by the developer in module.properties. |
| SchemaVersion | Current version number of the module's schemas. Controls the running of SQL schema upgrade scripts. |
| SourcePath | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The location of the module source code. |
| SupportedDatabases | Add this property to indicate that your module runs only on a particular database. Possible values: "pgsql" or "mssql". Note that support for mssql as a primary database is only supported for existing premium users of it as of the 24.7 release. |
| URL | The homepage URL for additional information on the module. |
| VcsRevision | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The revision number of the module. This will be displayed next to the module in the site admin console. |
| VcsURL | This value is set internally by the build, and does not need to be provided by the developer in module.properties. The URL to the server that manages the source code for this module. This will be displayed next to the module in the site admin console. |
| Author | Comma separated list of names and, optionally, email addresses: e.g. "Adam Smith <adams@someemail.com>, Kevin Kroy" |
Properties Surfaced in the Admin Console
Module properties are visible to administrators via
(Admin) > Site > Admin Console > Module Information. Click an individual module name to see its properties.
If you having problems loading/reloading a module, check the properties
Enlistment ID and
Source Path. When the server is running in devMode, these properties are displayed in green if the values in (the generated) module.xml match the values found on the server; they are displayed in red if there is a mismatch.
The properties for deployed modules are available in the table core.Modules, where they can be accessed by the standard query API.
Properties for File Based Modules
File based modules do not go through the same build process, and will show only a minimal set of module properties in the Admin Console. Seeing many blank lines is expected.
Related Topics
