It turns out that i cannot download the latest version (0.10.6) of the reporting module from modulus simply because it is sorted way down off the bottom of the visible page. Thanks @mseaton for pointing that out to me and MOD-89!
Does any one wanna fix it?
This modulus beast seems more complicated for not much practical value compared to our old school java based module repository. Yes it did not provide REST, but who seriously uses it anyway?
It would be great if someone can successfully build the module repo on their local machine (perhaps by using docker to get a particular version of java and grails that make this replicable for others). I didn’t have time to get to this.
I needed to do two things: (1) change a REST call to fetch a larger list of module versions, and (2) test my sorting algorithm.
The trick was to do get access to the right Angular scope by doing “inspect element” on a element in the UI that has the right angular scope, and then doing:
var scope = angular.element($0).scope()
I could also define the sorting function at the top level by pasting its definition into the js console.
I decided to burn a few hours on this, and I was able to use docker to build a java 7 + grails 2.3.7 image that I can use to compile the modulus API code.
I was able to reproduce the underlying API error (about sorting versions in the wrong order), and I have a fix for this, but (1) a bunch of tests are failing, and (2) I haven’t bothered with the relevant docker-compose setup to actually be able to run the app against a mysql database.
I’ve committed what I have, and hopefully someone else will be inspired to carry this further.
I spent (too much) more time on this but I successfully got a modulus dev environment running! And I can help anyone do it
I was not able to set up a vagrant dev environment to build modulus.
Specifically, when I set up a linux OS + Java 7 + Grails 2.3.7, then type “grails -v” it clears the screen, and then shows me a shell prompt, as if grails crashed silently. I tried with various linux flavors (precise64, trusty32, trust64, and centos7) and both oracle jdk and open jdk. And I got the same error behavior. (I was able to get the latest grails to run, but not the old 2.3.7 that we need.)
I was able to run modulus using some docker hackiness.
I used docker to set up an environment with java + grails, and copy my modulus-config.groovy into it (that’s the hacky part).
Then I use docker-compose to wire it to mysql.
Finally I needed Robby to create an oauth token for me on the production openmrs id server. (I can privately share this with any trusted dev who is going to be working on modulus.)
Unfortunately I could reproduce the bug that Ada ran into this morning, so all this effort was wasted, at least for now. And I can’t reproduce that error on modules-stg either…
Yes, we plan to move away from Modulus, and time spent on modulus is generally poorly spent. (Definitely nobody else should spend hours figuring out a dev environment.)
However making specific modulus fixes can be worthwhile. Particularly I wanted to fix the version sorting bug, which we really should have been treating as a blocker (i.e. it was impossible to download the latest reporting module from modules.openmrs.org). But, keeping your point in mind Mark, I deployed a one-older version of the modulus-ui code that fixes the version sorting in the UI layer, and I’m going to stop spending time on this now.
(We paused making a decision on going to bintray because we were waiting on a potential offer from JFrog to give us a free open-source instance of Artifactory, to consider how those compared. Per this thread I think Rafal and I are thinking that if we haven’t gotten an answer from them by the end of the year, we should just proceed with bintray or with github releases.)