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? 
There’s a REST API for Modulus too…
@dkayiwa, I have written a hacky fix for this bug, and I’m testing it out now.
To deploy the fix to production, I’m also going to have to deploy a bunch of changes made to modulus-ui over the last year or two, including GCI (mainly merged by Elliott).
I have deployed these to https://modules-stg.openmrs.org ; please click around a bit and see if everything seems to be working correctly there. I plan to push this to production tomorrow.
@darius, thanks for being a hero on this. We really need to get ourselves in a better place with our module repository. I’d love to learn more about how you did this in the javascript console - that sounds like a great trick.
Thanks very much, Mike
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.
Then I did something like this in the js console:
$.getJSON("url", function(response) { scope.moduleVersions = response; });
response.sort(function(a,b) { return -myInternalSortFunction(a,b); }
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…
Wasn’t there a movement to move all the modules to bintray (or elsewhere) and would time be better spent working on that?
Mark
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.)
That was granted iirc. So time to unpause!
FYI my thoughts about what we should do replace modulus are here: Replacing Modulus: Design Thoughts
Maybe it’s a silly proposal, but would it be feasible to store the modules in Confluence/JIRA and develop a plugin to manage them?
I imagine that a confluence plugin would be harder for the OpenMRS community to maintain than something standalone built on Spring.
In my comments on the other thread I’m suggesting that we should change what modules.openmrs.org is, so that instead of storing modules, it just indexes them.