Bintray: Better method of distributing apps?

I’d like us to consider the best way to distribute OpenMRS Open Web Apps and bundle them easily with the Reference Application. I see it as a chance to reconsider how we currently distribute openmrs platform and modules.

Currently we use the OpenMRS maven repository to publish omods. This repo is used for fetching dependencies when building modules, but also for creating a bundle of modules for the Reference Application distribution. In addition to that we use to distribute omods for end users. Furthermore we publish the bundle of modules (the Reference Application) to sourceforge. That’s a lot of different distribution channels already.

Now we need to distribute yet another package that is OpenMRS Open Web App, which is basically a zip.

In the current setup we rely mostly on our infrastructure to distribute releases. We have our own maven repository and modules repository. It feels too much for our community to maintain. I think we should be putting efforts in creating better platform and modules and not distribution tools.

To give an example that we are not doing good at maintaining distribution tools is that a simple bug of sorting versions of modules is broken on since the beginning of the repo, which at times leads to not showing the latest version correctly. Since we are using our own solution we still haven’t been able to implement a REST interface to publish to directly from maven or CI.

At the same time there are tools out there, which already have all we need and are free for open source projects. A good example is Also there’s no reason to maintain our own maven repo when most projects simply publish to maven central (bintray integrates with that too). Even sourceforge is easier to publish than

Writing this I’ve realised we have a GSoC project to build a repo for OWA, but please let us reconsider using something already available in the market rather than investing more in our own solutions.


Thanks for bringing this up @raff. I tend to agree. I have liked the premise that our own module repository could evolve to be something more, whether that involves ratings, or more OpenMRS-specific things, like being able to inspect config.xml and other files within modules and OWAs to be able to present broader information on version compatibility with the platform and other modules. But the fact is, over many years now this has not happened.

I would definitely welcome the chance to discuss the pros and cons of maintaining our own module repository +/ OWA repository and sourceforge site, with something like bintray as you point out.

Thanks, Mike


I agree that the promise of having OpenMRS devs help improve our own internal apps like Modulus, Dashboard, etc., has been very disappointing. (This by no means is meant to diminish the handful of people who have contributed; thank you!!) We have missed a lot of opportunity by not prioritizing this type of work within our general development management and project management processes. (Sarcasm intended.)

I did want to put out a point that a lot of people think Sourceforge is “dying” as a resource (particularly after their advertising scandal a year or two ago) and that there’s great need for a better service particularly for large file hosting … so I would caution investing too much effort into it.

I haven’t looked too much at Bintray yet, but it’s worth seeing if there are any new alternatives out there yet. Has anyone looked at GitHub’s latest solution for hosting binary files?

I would also support retiring our Nexus server if we can get away with it and the same functionality is available through other resources like Central.

Thanks @raff for keeping this in mind and helping lead the conversation on it. It’s an important consideration, and personally I would like us to always be using best-of-breed solutions wherever we can, so perhaps there’s opportunity here for that.


I would like to see where this is going. As much as I would not like to admit it(considering the fact that i applied to work on the OWA Appstore for GSoC), i think @raff has a point. I think we really need to reconsider the way we distribute our apps. But i don’t think we our actually short of devs to maintain our distribution tool, the thing is that it has not been given very high priority. That been said i agree with the point @raff made that we should concentrate on creating a better platform and modules and make use of the already available distribution tools. I believe we should definitely investigate these tools and see if they will serve our purpose.


Thanks @raff and all for this discussion.

I had a quick look at Bintray and it looks really good. I’d propose possibly modifying the current GSoC project to implement a proof of concept OWA app store backed by Bintray (after first making sure there isn’t anything better out there) in order to properly evaluate it.

If that seems to work, then we can at least be informed for a discussion about moving everything over.


FYI, anyone who wants to be added to the openmrs organization on Bintray for testing, please ping @pascal or me.


@michael @pascal i would like to be added to the list of testers.


@pascal, we’d like to try releasing Concept Dictionary OWA to bintray next week. My profile is

@raff I invited you. When you join I’ll make you an admin.

I already created owa and omod repos, with the idea that we should host each extention type in it’s own repo. What do you think?

Why not:

@pascal @michael Bintray is awesome and please add me to the list of testers.

Sounds good!

I agree with the sentiments here that (a) building our own solution has not worked out for us, and (b) at a glance bintray looks like it has all the features we need.

(As a vote of confidence for that platform, Bahmni is using bintray to distribute its RPMs:

Two lessons that we all should learn from the module repository experience:

  1. If OpenMRS chooses to write its own code outside of the core MRS/EMR/EHR space, it’s imperative that the dev environment is trivial for someone new to set up, and that the deployment process is automated so that someone new can take it on.
  • I know the module repo team actually spent a lot of time on making a dev environment available, but sadly the technology they were using disappeared. The sub-lesson is: if it can’t have a README based on solely industry-standard commands (docker, vagrant, git, mvn, gradle, npm, …), then we shouldn’t do it.
  1. If we think custom development is worthwhile, prefer a model where we outsource the bulk of the work to someone else’s hosted back-end that provides a REST API, and only write the OpenMRS-specific front end ourselves. For example, hypothetically:
  • could be a dashboard that shows highlighted and popular modules and OWAs, but then just passes you on to bintray for everything else
  • have a custom “compatibility with my OpenMRS installation checker”
  • have a custom “upload omod file” page that automates putting a file in the right place in bintray

An interesting data point that I came across randomly today.

If you go to you’ll see:

This portal is for Grails 1.x and 2.x plugins. Grails 3 plugins are available in Bintray.


It was super easy to setup releasing to bintray with travis-ci. I’ve just added bintray package descriptor at

and travis-ci config at:

In order to release it’s enough to push a tag to github and the release is automatically built and published to bintray.


Amazing, thanks for setting that up @raff!

where do I find the api key :confused:

You find it here: (then click on API Key). This is not an intuitive place to find it.

1 Like

Oh wow – that’s not at all.

:bulb: Possible Gotcha :bulb:

This goes without saying, but read the section in the manual about key concepts and take note of the virtual filesystem. As a result of this design, you cannot upload a file with the same name to two different versions.

This may seem strange and counter-intuitive, but apparently Bintray was designed to host repos with fixed layouts (like Maven).

The workaround is to specify the Target Repository Path when uploading a file (see docs). I’ve been using the version number as the path (see here).

p.s. Look at how cool the Docker image rendering is! Try clicking on the layers.