Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

Primary mentor

Rafal Korytkowski

Backup mentor

Burke Mamlin

Assigned to

Chris Niesel


We want to offer module developers a more friendly development environment like the one provided by e.g. Atlassian.


  1. Make it possible to run OpenMRS with an in-memory/embedded DB (configuration free and fast development setup thanks to skipping liquibase scripts, requires small changes in core)
  2. Deploy a module to any version of OpenMRS straight from the maven module archetype (requires modifications in maven module archetype)
  3. Improve the OMOD Reloader Module to read configuration continuously without restarting OpenMRS, create a configuration page to change settings straight from webapp
  4. Package OpenMRS SDK. Consider one of the 2 approaches:
    1. Package maven and simple bash scripts in a zip file which when unpacked on different Windows/Linux/OS X will let you run: (this is a MUST have)
      1. omrs-create-module -- invokes the archetype & walks through creating a module
      2. omrs-run -- runs the module in the current directory (build module & deploy it into an OpenMRS instance)
    2. Package JVM, maven and jgit. See for example (this is just nice to try)
      1. Create a module (backed by the maven module archetype)
      2. Build and (re)deploy a module to any version of OpenMRS (backed by the maven module archetype)
  5. Update documentation on the wiki and create a screencast

Extra Credit

  1.  Add more features to the OpenMRS SDK application e.g.
    1. Clone any repository from github
    2. Get latest changes
    3. Create topic branch for a ticket and push it to fork

Timeline (approx)

May 25 – June 16 (Community Bonding Period):

  • Get to know my fellow peers and co-workers
  • Throughout this period, I will as always be available on IRC to further discuss the proposal with members of the OpenMRS community so that I will be able to adjust or add things that I may have not thought of before.
  • I will be actively engaged in discussions with my Mentor to further understand and agree on what exactly needs to be modified so that OpenMRS will be able to function with an embedded database, while also examining where improvements in the reload module need to be made.
  • My Mentor and I will also be looking at the options presented previously, on how best to approach the deployment of the SDK on various operating systems. This will include the installation itself as well as the use of scripts.

June 17 – July 17:

  • Consult with developers and mentor on the wants for the embedded Database
  • Work on integrating the chosen database
  • Make sure OpenMRS is able to function properly with the implementation

July 18 – Aug 11:

  • Determine the best way to package the SDK
  • Consult with Mentor and peers
  • Work on packaging of the SDK
    • Commands (minimum):
      • omrs-version
      • omrs-create-project
      • omrs-run
      • omrs-debug
      • omrs-create-module
      • omrs-build
      • omrs-clean
  • Test to see if everything works

Aug 12 – Aug 31:

  • Modify maven archetype settings for easy deployment of modules (involve Chris Briesemeister in discussion)
  • Create scripts for both Linux and Windows to allow for module creation and deployment to OpenMRS instance
    • Possibly consult Atlassian SDK scripts 

Sept 1 – Sept 16:

  • Work on improving the reload-module for seamless integration
  • Discuss the wants and needs, set up a list of things to accomplish
  • Test and debug the improved version of the module

Sept 17 – Sept 23:

  • Work on screen cast and updating documentation
  • Check code for quality and make sure all works well
  • Write tests, if there need to be any


  1. Atlassian SDK
  2. Video overview of Atlassian SDK
  3. JavaFX self-contained packaging
  4. OpenMRS-SDK-proposal.pdf


  1. Chris,

    Excited for the project.  I would strongly recommend getting an SDK that works on all three major OSs (Mac/Windows/Linux) and successfully performs a single function (e.g., omrs-create-module) as your first priority.  It's a vastly easier task for another developer to come along later and add the next feature to a working SDK than it is to get a 95%-completed SDK through the remaining 5% needed to make it functional.  One of the biggest challenges with GSoC projects is when the "100% useable" comes at the end of the summer and, if it's not reached, we end up with 5% remaining that nobody has the time to complete.  On the other hand, if you create a 100% fully useable & tested SDK with minimal functionality and get that done earlier in the summer, you can iterate on adding features; then no matter when the summer ends, there's a fully functional SDK with whatever features you've managed to add up to that point.  See The Story of the Floss(smile)



  2. What does omrs-create-project do?


    1. Hi Burke, sorry for the late reply. the create project command creates a folder with a modified maven archetype that can be run with omrs-run.

      1. Modified version of which maven archetype?  When would a developer use create-project?  Presumably not to create a module.

        1. Burke, it's an archetype similar to openmrs-distro-referenceapplicaiton. We will store there a default version of OpenMRS used to test a module (which you can always override with a parameter) and a set of other modules (e.g. required by our module). In other words it will describe a full dev environment to develop a module. In the first pass SDK will download binaries for OpenMRS, modules and start the dev server. In the future we will make it possible to checkout code of specified modules, pull changes and build.

          1. Why do we have to put this burden on the module developer?  Can't a module be tested & debugged using OpenMRS artifacts without downloading all the source for the core application?

            1. SDK will only download binaries of OpenMRS and modules to test & debug - no source code.