We are finalizing the process of migrating from module distribution channels managed by our infra team to Bintray and cloud Artifactory. It is possible thanks to the generosity of the JFrog company, who is hosting us for free!
The Add-ons Index is hosted on OpenMRS maintained servers. However, it is a lightweight application using Bintray as storage backend.
As a reminder the migration entailed:
Moving away from Nexus to cloud Artifactory for mavenrepo.openmrs.org, where we store jars and omods for development.
Modulus will continue to operate for 2 weeks and is periodically synced to Bintray and available under https://bintray.com/openmrs/omod, which is also indexed by the Add-ons Index. After 2 weeks we will point modules.openmrs.org to the Add-ons Index and take Modulus down.
If you release your module to mavenrepo.openmrs.org, it is automatically published to Bintray and visible in Add-ons Index so there’s nothing you need to do other than forgetting about manually releasing omods to Modulus.
For any new modules, which are not community maintained (not hosted at https://github.com/openmrs), we kindly ask you to publish them under your Bintray account (both maven and omod artifacts). It will help us to scale and take off the maintenance burden from the OpenMRS community. Please see updated instructions on the Module Release page.
Please let me know, if anything needs to be better documented or you need individual assistance.
We are also looking for volunteers, who will go through our wiki pages and look for places, which mention releasing module to Modulus and update them accordingly preferably by pointing them to the Module Release page. Let me know, if you are interested and we can work together to help you identify such pages!
Just to confirm, at this point going foward there is no manual step required when releasing a core OpenMRS module to publish it to Add-ons? It automatically gets deployed to Bintray from Artifactory?
I released a new version of the Provider Management module on Friday and manually uploaded it to Bintray, which may not have been required? (And which I potentially put in the wrong place?)
I tried to confirm that it’s in Add -Ons, but I can’t get to addons.openmrs.org right now… is that still the correct URL?
To point out: we have added (almost?) everything that was in Modulus into the Add On Index, and this definitely includes all the modules that were in the reference application.
@raff Thanks alot for the Information. i think we also need to ripple these changes on the concerned wikis to smoothen the work for future Release Managers.Beginning with RefApp 2.7 upwards.
@cintiadr, yes, let’s do it! modules.openmrs.org should redirect to addons.openmrs.org. We need to schedule it. Before we shut if off I need to run a script to sync Bintray and modules one last time. Let me know when you have some time to do it.
@raff am willing.However got a question is it a manual search or there is a tool to accomplish just that?However i may take it on after am done with releasing RefApp 2.7,if no other folk has shown interest…
We need to test and verify that the OpenMRS API’s ModuleFactory can
correctly get updates and new versions of modules from add-ons. (I who
wrote a unit test for it, but someone should really test this in real life
before we make the final switch.)
However when openmrs-core finds a module update with that filename and downloads the file, it ends up naming it “download_file”, which fails to load (since it doesn’t have an omod extension), and OpenMRS then deletes both the old and new files from its modules folder.
I’m not sure how to approach this.
The hacky approach is to change addons.openmrs.org so that it indexes the first redirected url instead of the one we’re currently indexing. (Or maybe we can just expose that url for this legacy behavior.)
The right way would be to fix openmrs-core so that it handles the “response-content-disposition” header (and ideally uses an existing library instead of custom url-redirect-following code that we’ve written in OpenMRS).
The problem is that implementations running existing releases would have a pretty annoying bug if they try to update modules via Manage Modules in the legacy UI (or presumably in the new OWA UIs for this, because it’s a core bug) where trying to update a module actually deletes it.
I doubt I’ll have the time to play with that (and it’s not even my expertise :D) , but if anyone wants to go for http requests manipulations of any sort, that’s the place and the right box.
I agree with @cintiadr, the solution for this is to use nginx to rewrite the url/headers as needed to make the legacy code happy. Would something like this help?
After my previous post I realized that I can work around this issue with a very localized hack in the Add On Index code. (Here is the commit, if anyone cares.) I prefer to do this versus having an nginx rewrite because it keeps the hacky business login in the server that’s actually serving these requests.
So, I no longer have any objections about turning modulus off and pointing its hostname to addons.