OpenMRS SDK 3.1.1. released!

raff · August 4, 2016, 11:21am

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:

Building and deploying all watched modules with one command: mvn openmrs-sdk:build
Pulling changes for all watched modules: mvn openmrs-sdk:pull
Forking and cloning any repo: mvn openmrs-sdk:clone
Creating and updating pull requests with automated pulling of latest changes and squashing: mvn openmrs-sdk:pr
Improving module creation wizards
Adding support for running database docker containers before starting up a server
Releasing to bintray: mvn openmrs-sdk:release (currently only maven jars, but shortly will release omod as well)
Adding anonymous usage statistics (you can opt-out).
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 http://om.rs/sdk for more documentation.

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

ssmusoke · August 4, 2016, 12:54pm

@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 https://gist.github.com/ssmusoke/c60c5d0d424e81e7dc1687828303ed51

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”

raff · August 4, 2016, 12:58pm

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 https://issues.openmrs.org/browse/SDK-135)

ssmusoke · August 4, 2016, 1:02pm

@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

raff · August 5, 2016, 8:06am

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

ssmusoke · August 5, 2016, 8:14am

@raff Works like a charm

raff · August 5, 2016, 8:27am

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?

raff · August 5, 2016, 8:32am

@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.

ssmusoke · August 5, 2016, 8:35am

@raff I have an openmrs-distro.properties 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

raff · August 5, 2016, 8:39am

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

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

ssmusoke · August 5, 2016, 8:53am

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

raff · August 5, 2016, 8:56am

@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?

adamg · August 5, 2016, 9:00am

Sure @raff, I will take a look at it

adamg · August 5, 2016, 9:40am

Hi @ssmusoke, I believe you’ve updated the openmrs-distro.properties 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 openmrs-distro.properties 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 ? ?

ssmusoke · August 5, 2016, 9:43am

@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.

adamg · August 5, 2016, 9:48am

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

ssmusoke · August 5, 2016, 9:56am

@adamg Works like a charm.

Questions:

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

Then can this file be made a standard say serverid-distro.properties which can override the distribution setup

raff · August 5, 2016, 9:57am

@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 https://github.com/PIH/openmrs-module-mirebalais#set-up-pih-emr-distibution with distro file at https://github.com/PIH/openmrs-module-mirebalais/blob/master/api/src/main/resources/openmrs-distro.properties

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?

adamg · August 5, 2016, 10:32am

No, properties file has to contain all the modules.
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

ssmusoke · August 5, 2016, 11:19am

@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?