The future of Modulus

Hey all,

So Modulus had a real need for our community at one time. Since we are moving towards OWA’s now, it is worth taking consideration to retiring Modulus(NOT Modulus UI), I’m talking about getting rid of the Grails app that nobody seem to want to maintain. It would alleviate our already strained infrastructure resources, and remove one thing that we’d have to be responsible for as a community.

What would we do? We’d use bintray for everything. Metadata would be stored there, everything.

Opinions? Let’s discuss this.

1 Like

I think it’s a good idea. Additional context available here.

1 Like

We’d still need to modify Modulus UI to not use the grails app anymore…it might need to be refactored a bit but we remove one piece of software that we don’t have to maintain anymore.

I definitely agree that using hosted bintray instead of running our own modulus server application makes sense in the long run. But I don’t think a pure refactoring of modulus-ui to use a different back end is worth the effort of code rewrite + data migration.

Doing this in the context of adding new functionality would make more sense. E.g. it makes sense to do this in the GSoC OWA store project.

On the related thread I suggested we should in fact also rewrite the UI from scratch: OWA App Store GSoC project

How much functionality does modulus-ui have that we want to maintain versus how much would we get rid of with a bintray back end? (This is an honest question, not a rhetorical one.)

My initial thought is that what we’d want in our module/OWA store in a hosted-on-bintray world is quite different from the current functionality, which is why I suggest a rewrite of an essentially different application, that is mainly about indexing things hosted elsewhere.

-Darius (by phone)

1 Like

A new app means we have to host a new app…which we barely can handle what we have right now. The community needs to step up and help to maintain Modulus…nobody seems to want to do it and I value my sanity right now.

Robby does make a good point we should remember. If you look back at the discussions several years ago, one of the main drivers of building Modulus instead of forking Zamboni, was that writing a Grails app would mean that everyone in the community would help maintain it.

Now, there are several reasons why that didn’t happen, but we need to both make more of a commitment as well as ensure that any new app is built in a way where there will be “no excuses” for folks to contribute patches and changes. :slight_smile:

1 Like

One thing I’d point out regarding modulus is that it suffers from the problem that the itch is not bad enough for many of us to scratch, left to our own devices.

For our purposes at PIH, the Nexus maven repository has generally taken over as our hosted platform for distributing and installing omods, using this and a distribution profile in our top-level EMR modules to pull in all of the omods that we need at any given point in time. We can get to the majority of omods that we want to use, including published snapshots, this way.

This isn’t meant to be commentary on the usefulness of an improved module repository, but just one reason why we (and others I suspect) have not prioritized modulus development over other projects.



Then why not just kill Modulus? If nobody maintains it, it will just happen naturally.

@r0bby, I completely agree with you, but maybe that wasn’t clear, so let me be more explicit:

If we shift to hosting our modules externally (e.g. via bintray) then the current Modulus UI has very limited functionality that we’d want to preserve (basically, searching for in a simple UI). Also, the current codebase is not getting sufficient community maintenance.

Therefore, I suggest we should be dropping both modulus and modulus-ui, and instead starting from scratch with a new app that is lightweight and easier to maintain going forwards.

True, but I think this is a secondary cause and not the root cause of modulus not being maintained. The real issue is that it’s very hard to set up a modulus dev environment, so I personally stopped asking people to contribute to modulus until this was addressed.

The new application (at least as I’m envisioning it) will not suffer from this problem because (a) it should be a standard npm app, and (b) it will not depend on OpenMRS ID. And that will make all the difference to getting community support.

(I envision that the new application is a read-only index of omods and OWAs that may be hosted in various bintray accounts, or perhaps other places too. But you would actually upload, rate, comment, etc, via bintray directly. Hence no OpenMRS ID.)

I suppose…I’ll just have to wait and see how it pans out…

I think keeping OpenMRS ID integration is a good thing. I’m going to speak to JFrog at OSCON and see if it’s possible to do Single-Sign On (SSO). How do you envision authenticating users?

In my view there is no need to authenticate to our app. (It’s read-only.) You would log in to bintray to upload module versions, etc, via a bintray account.

If we can provide SSO with OpenMRS ID that’s a nice to have, but not required, just like github is not part of our SSO world. (Also, per my last message, any auth requirement should not make the dev environment setup harder.)

-Darius (by phone)

1 Like

I’m honestly in favor of anything that means it’s easy to develop. I’ve tried to make ID Dashboard easier to start up (hence my dockerizing it)…

Oh right, that’s great! Can you please update the modulus readme in github and this wiki page to mention this? I’d like to try fixing the wrong-version-sort-order bug.

Sure – I’m in the process of fixing the fact that they renamed jade to pug due to someone owning the trademark for jade – yet another FOSS project forced to change their name due to some trademark issues.

In a nut-shell – grab the ID Dashboard code, install docker-compose, you already have docker, I assume you have vagrant installed then do:

npm install ; npm run bootstrap

There is a caveat – I plan on fixing this – it doesn’t seem to delete the lock file that mongodb places for the db – so occasionally you will have remove /docker/mongo/mongod.lock if you get errors that it cannot connect to mongo and do docker-compose up -d --force-recreate mongodb

Don’t put the instructions on this thread, put them where they really belong. :slight_smile:

-Darius (by phone)

I was busy at the time doing something else – now I’m free – I’ll do it later today. Something else took priority.

@darius, I got it running and was able to successfully authenticate to my development ID dashboard instance via oauth…I will update the docs this weekend. There are however some small issues I ran into, namely that the current version of grails we are using does not work with Java 8.