OpenMRS SDK 3.1.1. released!

I’m pleased to announce the 3.1.1 release of OpenMRS SDK! Once again thanks to Soldevelo for making it happen! @adamg, @gutkowski, @tmarzeion worked hard to implement the following features:

  1. Building and deploying all watched modules with one command: mvn openmrs-sdk:build
  2. Pulling changes for all watched modules: mvn openmrs-sdk:pull
  3. Forking and cloning any repo: mvn openmrs-sdk:clone
  4. Creating and updating pull requests with automated pulling of latest changes and squashing: mvn openmrs-sdk:pr
  5. Improving module creation wizards
  6. Adding support for running database docker containers before starting up a server
  7. Releasing to bintray: mvn openmrs-sdk:release (currently only maven jars, but shortly will release omod as well)
  8. Adding anonymous usage statistics (you can opt-out).
  9. Building Open Web Apps with mvn openmrs-sdk:build

and more smaller fixes and improvements…

The update is being slowly rolled out to anyone using SDK, but you can always upgrade right away with:

mvn openmrs-sdk:help -U

To start using the SDK run:

mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:setup-sdk

Please refer to for more documentation.

We are looking for your feedback and ways on how to improve!


@raff Thanks for the excellent work on the SDK

I upgraded immediately and created a new Ref App 2.5-SNAPSHOT distribution server with an existing database, on running it I get the following error

Environment: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T19:41:47+03:00) Maven home: /usr/local/Cellar/maven/3.3.9/libexec Java version: 1.7.0_80, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: “mac os x”, version: “10.11.6”, arch: “x86_64”, family: “mac”

Thanks @ssmusoke! We’ll fix it ASAP, but it may take up to a few hours for the update to be propagated.

It should work without specifying port though.

(addressed in

1 Like

@raff I am using the port as I am already running Tomcat on 8080, and with the new build tools, I may just move to the SDK for all my OpenMRS dev work

@ssmusoke, version 3.1.2 is out and should be working.

1 Like

@raff Works like a charm :clap:

1 Like

Hi @mseaton,

I’m reaching out to you as I’m curious if the way we implemented build and pull commands for watched projects is a good enough replacement for your custom shell scripts.

Once you create a server, you can call

mvn openmrs-sdk:watch -DserverId=myserver

in any number of modules’ directories you are currently working on.

Then you can call:

mvn openmrs-sdk:pull openmrs-sdk:build -DserverId=myserver

and you will have all watched modules updated to the latest upstream master and deployed to the server.

The pull command stashes uncommitted changes, does pull rebase on the currently checked out branch and pops stash back. If there are conflicts it reverts to the original state and asks you to pull changes for that module manually.

We also have a complimentary feature, which is capable of deploying the latest SNAPSHOTs built by CI (you don’t have to have any repositories cloned) by calling:

mvn openmrs-sdk:deploy -DserverId=myserver

It makes only sense if you setup a server pointing to a SNAPSHOT version of a distro, which has SNAPSHOT versions of modules, e.g. Reference Application 2.5-SNAPSHOT:

mvn openmrs-sdk:deploy -DserverId=myserver -Ddistro=referenceapplication:2.5-SNAPSHOT -U

Are there any missing features, which prevent you from using SDK instead of your custom shell scripts?

@darius, does the way we implemented the Docker DB container support satisfy you? Let us know once you have a chance to try it out.

@raff I have an file where I updated the version number of a module, in this case for Ref App 2.5-SNAPSHOT I increased metadata deploy to 1.7 from 1.5. How can pull the latest version of the new module into the directory.

mvn openmrs-sdk:deploy -DserverId=myserver does not seem to do this

@ssmusoke, if you want to deploy updated versions to a server from a locally updated file, then you just need to run the deploy command from the directory with file or point to that file:

mvn openmrs-sdk:deploy -Ddistro=path/to/ -DserverId=myserver

@raff only snapshot versions are updated, but for non-snapshot versions omods are not downloaded

@ssmusoke, that’s a bug… I noticed it asked me to confirm the update, but it didn’t update the omod eventually. @adamg, could you please have a look at it?

Sure @raff, I will take a look at it :slight_smile:

Hi @ssmusoke, I believe you’ve updated the file in your server’s directory ? This won’t work, because we use this file to calculate difference between the file in directory passed via -Ddistro and the one in server’s directory(In your case it was the same file). After that the is updated. So I wouldn’t call it a bug, we just didn’t consider this use case. We can of course change current logic to support this. What do you think @raff ? ?

@adamg That is what I did since the distro has a lower version of the module than what I need, and hence failed to start. Otherwise the question is how can I use higher versions of the modules that are defined in the distro.

First thing you need to restore your orginal file. Then copy it out to any other directory and change modules versions. After that you can call deploy from this directory.

@adamg Works like a charm.


  • Can the new file, only contain the modules that I want updated or does it have to contain each and every module included in
  • Can the new file contain new modules to be added?

Then can this file be made a standard say which can override the distribution setup

@ssmusoke, by following what @adamg suggested you will in fact create a new distribution. I’d suggest changing name and version of the distro in the file as well. You can give away the distro file to any developer so that the server is easily replicated with your versions of modules. See for example how Mark created Mirebalais distribution at with distro file at

Alternately if you just want to update a module for yourself, you can call deploy and select a module you want to update.

@adamg, good finding! I think it would be good to drop all modules specified in the distro and copy them again to the server when calling deploy distro. Just to be sure the versions of omods are in sync. Could you please ticket it?

  1. No, properties file has to contain all the modules.
  2. Yes, new modules will be deployed and added to the server’s distro properties file

@raff We have an idea with @gutkowski how to support updating modules as @ssmusoke was trying to do by editing distro properties file in server’s directory. I will create ticket, so you can approve it or not :slight_smile:

@adamg won’t having only those modules that change make the process more efficient for managing updates especially as the number of modules grows across distributions?