OpenMRS 3.0 Reference Application

This project holds the build configuration for the OpenMRS 3.0 reference application, found on https://dev3.openmrs.org and https://o3.openmrs.org.

Quick start

Package the distribution and prepare the run

docker compose build

Run the app

docker compose up

New OpenMRS UI is accessible at http://localhost/openmrs/spa

OpenMRS Legacy UI is accessible at http://localhost/openmrs

Overview

This distribution consists of four images:

• db - This is just the standard MariaDB image supplied to use as a database
• backend - This image is the OpenMRS backend. It is built from the main Dockerfile included in the root of the project and based on the core OpenMRS Docker file. Additional contents for this image are drawn from the distro sub-directory which includes a full Initializer configuration for the reference application intended as a starting point.
• frontend - This image is a simple nginx container that embeds the 3.x frontend, including the modules described in the frontend/spa-build-config.json file.
• proxy - This image is an even simpler nginx reverse proxy that sits in front of bot hteh backend and frontend containers and provides a common interface to both. Basically, this help mitigate CORS issues.

Contributing to the configuration

This project uses the Initializer module to configure metadata for this project. The Initializer configuration can be found in the configuration subfolder of the distro folder. Any files added to this will be automatically included as part of the metadata for the RefApp.

Eventually, we would like to split out this metadata into two packages:

• openmrs-core, which will contain all the metadata necessary to run OpenMRS
• openmrs-demo, which will include all of the sample data we use to run the RefApp

The openmrs-core package will eventually be a standard part of the distribution, with the openmrs-demo provided as an optional addon. Most data in this configuration should be regarded as demo data. We anticipate that data in the openmrs-demo package will be replaced by implementation-specific metadata, though they may use that metadata as a starting point for that customisation.

To help us to keep track of things, we ask that you suffix any files you add with either -core_demo for files that should be part of the demo package and -core_data for those which should be part of the core package. For example, a form named test_form.json would become test_core-core_demo.json.

Thanks!