We had a rough start with the OCL development, but we will still attempt to add support for collections to OCL API.
At the same time we’re looking for new projects to work on. If you have any needs for new features or bug fixes, please let us know.
Regardless I’d like the team and everyone who wants to help to next spend some time on fixing and adding new features to OpenMRS SDK. In 2-3 weeks I’d like us to:
Thanks @raff and the Soldevelo team for all the great work so far! I’m a huge fan of anything that makes developer’s lives easier, so I think the SDK sprint is an awesome idea. The more examples, documentation, videos, etc we can generate, the better.
Does it make sense to try and get the RefApp running on an in-memory (or embedded) database so developers don’t have to setup their own database instance to spin up a RefApp development environment using the SDK?
Yes, it does! To achieve that we need to help module developers to move database migration scripts from sqldiff to liquibase. SQLdiffs are often MySQL specific, thus fail on other databases. Rewriting is easy, but module developers are reluctant to do it or trust others doing it as it is troublesome to test many different upgrade scenarios.
Suggestion: create an utility to generate UI boilerplate (HTML, JS, controllers…) for CRUD screens. Similar to the SDK. Ideally it would allow to generate code for distinct JS frameworks / libraries (that would be awesome). It would be not a general purpose tool because the generated artifacts will use OpenMRS existing resources, APIs …
First of all, I would like to thank you and the team behind the SDK. I have been using it for about 3 weeks and it’s a big improvement versus what I was doing before and it’s become quickly a big part of my OpenMRS development workflow.
I think it is a tool that can be leveraged on in CI environments as well, we will definitely use it there too.
Since you are asking for suggestions, I wanted to comment on the install command. Unless I missed something, it seems that it is only copying the built .omod to the /modules folder of the target server. But it is not loading the module.
Would it be possible to have it actually load the module (= as in loading its activator) on the server? Or perhaps create a new command for that purpose?
There’s another possible approach to running the reference application in the SDK (and this is what I use in real life): use docker (or vagrant) to run mysql.
So, instead of refactoring every single reference application module, you could add the ability for the SDK to use docker to run mysql.
(And from the “similar-environment-as-production” perspective I would actually prefer this approach.)
+1 to the SDK as a whole and continuing development on it… admittedly, I was a latecomer in terms of using it, but have been impressed so far
+1 to the idea of finding a way to make MySQL easier to fire up in the SDK versus an in-memory database. It’s unfortunately, but I think refactoring all the modules to be database agnostic may not be something we want take on at this point, generally for the reasons @raff mentioned.
One additional suggestion (and I’m not fully up-to-date on all details of the SDK, so I might be offbase) is to NOT have different commands for installing the platform vs. the reference application, and certainly not to hard-code the supported versions of available releases and the modules+versions they contain, but to think broader than this in terms of “distributions” as we tend to define them as maven sub-projects in a top level “distribution module”.
By default, if I were to run “install”, this would install the platform.
But if I add a “distribution-artifact”, “distribution-version” to my install as optional parameters, then this will use the “distro” project pom as available to install the appropriate modules.
Some examples of distro poms that I know of and use regularly and would like to be able to “install” and “update”:
If we could ensure that such distribution POMs were regularly released into Nexus with appropriate versions, and the SDK was able to use the information in them to pull down and install the modules that make up that distribution, that would make it a lot easier for developers to use the SDK who support these distributions day-to-day.
Another bonus feature would be to enable passing a custom “starter DB sql” script to load for the install phase. This way, if an implementation can load whatever initial database metadata and configuration it needs to best match the production environment it is trying to replicate for development.
I meant to add - another variation on this theme, which could be mutually exclusive, would be to support running “install” or “install-distibution” from within the codebase of one of these distribution modules.
Reporting module cc @mseaton this is a pain point for many implementations …
We always need more help with radiology , but bigger tasks that can benefit core include cc @teleivo
a. A mature HL7 messaging system . Most of the modules using Hl7 hardcode their work and hence code is very buggy here
b. Cleaning up the EMR API module not to have too many dependencies … See radiology module: dependency on emrapi and Dependencies in EMRAPI module
@raff The SDK Sprint idea is great! I believe we had a conversation on IRC where talked about adding support for refreshing JSON extensions and even bundled messages, both of them which aren’t currently supported in the development mode. Maybe we could add those as tickets too
@mseaton, your run-distribution idea is very similar to what I meant in my 5th goal. Calling it distribution makes sense to me.
@darius, just a question regarding docker support. Would you like SDK to trigger docker run for mysql container before starting up a server? Or how would you see that support?
@judy, we could work on what you suggest, however I’m only clear on what is needed for cleaning up the EMR API. The rest needs more details. You could create separate topics on each project (or start from the one with the highest impact) and describe goals, needs and ideally point to specific JIRA issues.
I haven’t thought this through at all, but basically when I’m creating a server (e.g. for reference application) I’d like to be able to declare “I want the database in a mysql [5.6] docker container”. The SDK should both (a) configure the runtime properties file to point at that DB, and (b) ensure that docker container is running when I run the server.
Basically when I do a throwaway SDK server for some purpose I currently do something like this:
It would be awesome if there were a one-line way to do this so I didn’t have to look up the details each time. (Extra credit: be smart enough to create a docker volume in the sdk server’s folder.)
It would be neat if I can go to a module’s root directory and say just:
mvn openmrs-sdk:install
and since I didn’t specify a -DserverId=... it should ask me which server, based on looking at what servers I have installed, e.g. like
Which server do you want to install into?
hackathon
oneeleven
twofoursnapshot
The way things work now, I constantly need to look up the syntax of the commands, and also check what my various SDK setups are called. With this feature, I would actually be able to remember everything I need.
@darius, I may be missing something in your idea, but it seems to me it currently works as you describe. For example to deploy webservices.rest go to the module root directory, type
mvn clean install openmrs-sdk:install
to build the module and install to a server. Since you haven’t specified serverId, the sdk will print out the following:
Define value for property ‘serverId’: (default: ‘refapp-2.3’) (possible: refapp-2.3, refapp-2.3.1, mds-1-11, mds1-11, metadatasharing-release):
Module is installed already. Do you want to upgrade it to version ‘2.15-SNAPSHOT’? [Y/n]: Y
If it’s not the case for you, maybe you are using some older version of the SDK. Upgrade by typing:
It will last for two weeks and it will end with a new SDK release. Do not worry that not all requested features have been included. We’ll have two one-week follow up sprints to implement the rest.
As always everyone is invited to join! Please contact me directly, if you want to help!
I’m a huge fan of anything that makes developer’s lives easier, so I think the SDK sprint is an awesome idea. The more examples, documentation, videos, etc we can generate, the better.