...

Hibernate is an excellent Object Relational Mapper. Using just xml files, or annotations, we are able to describe the relationship between all of our tables and our domain (POJO) objects (like Patient.java, Concept.java, etc). Looking at the concept domain in the datamodel, we see that it consists of tables named concept, concept_answer, concept_set, concept_name. It would be very difficult to keep up with where to store each part of the concept object and the relations between them. Using Hibernate, we only need to concern ourselves with the Concept object, not the tables behind the object. The concept.hbm.xml mapping file does the hard work of knowing that the Concept object contains a collection of ConceptSet objects, a collection of ConceptName objects, etc. To add a new name to a concept:

...

Hibernate will not load all associated objects until they are needed – this is called lazy loading. The concept object above never dove into the concept_answer table to get the list of answers for concept 1234. If we had called concept.getConceptAnswers() Hibernate at that point would have made a call to the database to retrieve the answers for us. For this reason, you must either fetch/save/manipulate your object in the same session (between one open/closeSession) or you must hydrate all object collections in the object by calling the getters (getConceptAnswers, getConceptNames, getSynonyms, etc).

Liquibase

We use liquibase for database schema changes.

OpenMRS Source code

OpenMRS lives in a Git repository.  See the Code Repositories wiki page for more info.

Building OpenMRS

OpenMRS uses Maven to manage the libraries and build system.  See that wiki page for more info.

...

OpenMRS has a modular architecture, meaning that "modules" (i.e., add-ons or extensions) can be added to the system to add new behavior or alter existing behavior. OpenMRS Add-ons index hosts publicly downloadable modules; these can be installed directly from within OpenMRS as well.  See the Module documentation for developers.  Modules are allowed to interact with OpenMRS on every level.  They can provide new entries into the Spring Application Context, new database tables, new web pages, and even modify current service layer methods.

...

That spring descriptor file also contains settings for the max form upload size, locale changing, message names, fieldGen handlers, and name/address templates (to be removed: TRUNK-368 ).

NOTE: We moved away from the JSP server side technology to React based single page applications as you can find out the details at: OpenMRS 3.0: A Frontend Framework that enables collaboration and better User Experience

DWR

...