@raff What is the use of adding the openmrs.war in the RA release folder if it does not include the bundled modules, as this can be got from the platform downloads. All other artifacts make sense
I would suggest using OpenMRS_Reference_Application_(version) as it is clear what the download is.
If we do not include it, then it is not clear which war to use for that RA release looking just at sourceforge, unless we say it in readme.txt and ideally provide a direct download link. Also we only publish a war for platform with bundled platform modules…
@raff From an end-user perspective the war file that I download from the RefApp folder should include bundled modules - basically ready to go. This can be further explained in the readme.txt that you rightfully suggested
We are not re-releasing the openmrs-core WAR with each reference application release. So, we should have good (short) instructions in the README that describe how to install, or a link to those instructions.
We may want to have the README contain a link to a specific platform version. (However note that RA 2.5 was released on platform 2.0.1, but today I would suggest you install it on platform 2.0.5.)
@darius As a newbie user less than 18 months ago, and working with others who want to see what RefApp is capable of, I was very confused about how to get the RefApp up and running (platform is only for developers).
The best way to encourage this usage should be download a single WAR file, dump in a Web Application server and you are good to go rather than the “pure” OpenMRS way - download a WAR file install it, download modules, unzip, copy to some folder, restart web application server then you are all setup.
In our local resource constrained environments, and non techie users plus non Java conversant, this is too much to ask.
Why not try bundling the modules in a WAR file as an experiment for 2.6 and watch the community response?
My opinion is that we should not do what @raff is suggesting in the initial post, and copying one of our released platform WAR artifacts so that the same WAR can be downloaded from 2 places.
I’m open to “new simplified packaging” as suggested by @ssmusoke. It would simplify things a lot for newbie users. So, we’d release a war-with-all-modules-bundled, as well as just a zip of modules.
The downside is that it’s harder to upgrade, e.g. you couldn’t just replace the war from platform 2.0.1 with 2.0.5 when a platform maintenance release comes out, because you’d lose your modules. You’d need to wait for a refapp maintenance release, which we are currently not set up to do.
The ideal solution is probably to have a well-thought-out installer.
Going forward the folders should definitely be OpenMRS_Reference_Application_(version).
In the past there were a few version that we actually did (unwisely) name like “OpenMRS 2.0” (I think maybe also 2.1 and 2.2?) But for 2.3-2.5 the sourceforge folders are mistakenly named.
I think this is a viable compromise. Based on previous discussions, the RefApp platform releases are LTS releases, which is the reason why so much time is spent on them.
Given the platform approach of non-LTS releases, then maybe the Ref App can adopt a similar approach, which should not be many due to the 6 month release cycle, and could be driven by implementation-specific needs. Also with the excellent work done on the SDK, an implementation can easily build their own distro overriding just the needed set of modules to get their own WAR file for rollout.
