Some releases The OpenMRS Platform, the OpenMRS Reference Application, and other distributions of OpenMRS come with modules already prepackaged pre-packaged into them. These modules are packaged into the war file when it is being built if the omods are in the /webapp/src/main/webapp/WEB-INF/bundledModules folder.
...
An example of a "bundled module" is the FormEntry Module in all versions of 1.5 and 1.6. When someone downloads openmrsOpenMRS, the formentry module is automatically installed and running. The user can choose to uninstall or upgrade the module just like any other module.
To find a list of the currently bundled modules, look at the OpenMRS Reference Application Release Notes wiki page.
Uninstalling a Bundled Module
...
If a user has installed a module into their local machine that has a greater higher version than a bundled module of the same id, then the bundled module will not be loaded. If the module bundled with an OpenMRS distribution is newer (higher version) than , then the bundled module is used. If the versions match, the bundled module is favored.
Other Related Scenarios
- Required Implementation Modules (aka Core Modules)
- In some cases, a required service (part of the core application) is implemented through a bundled module in order for the feature to evolve faster than the core platform. For example, the OpenMRS Platform needs at least one implementation of the logic service serialization installed. The logic service Serialization is implemented in modules a module (instead of core) so that additional/alternative serialization methods can be created by adding or substituting the module(s). OpenMRS currently ships with the Logic Service implementation as . Both the Platform and the Reference Application distribtuion (which uses the platform) ship with the Serialization Xstream module as a core module. As long as one of these logic service modules a core module is installed, OpenMRS is happy; however, if there isn't any implementation of logic service availableprovided by a core module, some features of OpenMRS may not function properly.
- Required Once Installed (aka Mandatory Module)
- Some modules make irreversible changes to the database and/or track changes in a way that would break functionality if OpenMRS were running while they are unavailable or disabled. An example of this is the Sync module. Once installed, the Sync module tracks every change made so that the system can be synchronized with other instances of OpenMRS. If, after installing the Sync module, OpenMRS is run without the sync module actively tracking changes, then synchronization data would be corrupted. So, once the sync module is installed and running, it cannot be removed or stopped. If the sync module fails to start up properly, then OpenMRS will not be allowed to start until the problem is fixed.
Bundled Modules
OpenMRS 2.1
- Allergy API 1.0.1
- Allergy UI 1.0
- App Framework 2.2.1
- App UI 1.2.2
- Atlas 2.1
- Calculation 1.1
- Core Apps 1.4
- Data Exchange 1.2
- EMR API 1.4
- Event 2.1
- Form Entry App 1.0
- HTML Form Entry 2.4
- HTML Form Entry Extensions for OpenMRS 1.9 1.4
- HTML Form Entry UI Framework Integration 1.1 1.0
- HTML Widgets 1.6.5
- ID Generation 2.9.1
- Metadata Deploy 1.2
- Metadata Mapping 1.0.1
- Metadata Sharing 1.1.8
- Name Phonetics 1.4
- OpenMRS UI Framework 3.2.1
- Provider Management 2.2
- Reference Application (RA) 2.1.1
- Reference Demo Data (optional) 1.3
- Reference Metadata 2.1.1
- Registration App 1.0
- Registration Core 1.0
- Reporting 0.9.2.1
- Reporting REST 1.3
- UI Commons 1.3
- UI Library 2.0.4
...
- calculation 1.0
- htmlformentry 2.2.1
- htmlformentry19ext 1.4
- htmlwidgets 1.6.5
- logic 0.5.2
- patientflags 1.3.4
- reporting 0.8
- reportingcompatibility 1.5.8
- serialization.xstream 0.2.7
- xforms 4.2.5
...