Hello! I belong to a group of students who would like to get peoples’ input on an idea for a feature.
Idea
Our group wanted to know if people would like to have a GUI installer developed (nothing too fancy mind you) for the OpenMRS SDK.
Context
I am a student from the University of Nebraska Lincoln. In our Software Engineering class (261) we have been working with/around OpenMRS for a while (perhaps you’ve seen a couple of our posts). For the next 7 weeks, we have been given tasks to improve OpenMRS through documentation, testing and bugs/features. For our group’s feature implementation, we thought it might be a good idea to develop an installer for the OpenMRS SDK.
Justification
We came up with a few reasons why this might be helpful
The process for installing the SDK may seem a little long/convoluted and could be automated. While working on starting a test module, several people in our class found difficulty even installing OpenMRS. While in hindsight the process is not as difficult as initially thought, it is deceptively so at first which brings me into…
Google Summer of Code! With many new young coders taking a look at OprnMRS this summer, streamlining many of the more tedious processes, and making students feel confident they’re ready to code can be quite important. A frustrating installation can easily turn into a horrible experience.
Extensions to using the GUI for OpenMRS development. Currently, all of OpenMRS development, when it comes to starting servers, deploying platforms, etc. requires running commands in the terminal. While certainly easy for veteran developers of OpenMRS, new students might find this process tedious, intimidating or even confusing considering the amount of commands on hand. Additionally, a lot functionaliy is either hidden or non-existent. For example, how might a student stop a server if they want to. While the initial installation GUI probably won’t provide server startup GUI stuff like XXAMP does here, it very well could in the future.
Development and Design
Right now, we see this being a Java program completely separate from OpenMRS using either Swing or JavaFX. The actual commands to run the SDK won’t have to change as there are ways to run commands as if in the terminal in Java, as explained here. Even more, we can detect what OS is being used in Java. The program will likely load commands based on the OS from configurable files, making changing a command for the SDK and this installer extremely easy, with no requirement on understanding the inter-working of the actual installer.
Thanks for reading through this, and we’d like to know whether you (the OpenMRS) community would like to see this happen. Feel free to give any advice or suggestions as well. Just remember we only have 7 weeks so we can’t do everything.
Thanks for your proposal. When you say OpenMRS SDK are you referring to the latest version documented here?
I’m not quite sure it is the case, because installation is just a one-line command so let’s clarify it.
I’m supportive of any improvements to the SDK so let’s continue discussing having in mind we not only need to implement new features, but also maintain them in the future.
GUIs in particular are tricky for testing across different OSes. Did you consider how to do automated tests? How to deliver GUI upgrades with command line SDK upgrades?
Thanks for the response. To answer your questions:
Yes, we are referring to that line, but the installer would do more. We are generally thinking of the typical user of the installer to be someone who is assumed to only have Java installed, no set path, or JDK, or SQL, ect. The installer would try and find each of these, and then tell the user to get them if they do not have it. Effectively, the installee should not need to look at the Wiki page to install the SDK for any reason, although using it once installed is another issue.
We have thought of ways to make this quite maintainable. For one, the process of making changes to the steps of installation will need to be well documented in at least the module (likely readme). We have also thought of using a special file to define the process in readable and simple text, that could be edited for any updates, instead of having to edit the actual Java code. The file could look like this:
/* in file Windows/FindJavaPath.txt */
/*
* Block quotes are removed in the program before running this file
* Indenting used to identify code which uses the previous line's output
* There are three main variables, State state, boolean success and Stack outputStack
* - state controls which page/step the installer is on. Changing the state usually changes the page.
* - success is set if certain commands output true and such
* - outputStack contains the String output of the last command in the current scope, removing
* and adding as the scope increases/decreases
*/
/*
* run commandLineCommand: runs that command. outputs the text result
*/
/*
* test regex : tests the ouptut of the previous command versus the regex (to see if it exists).
* outputs the part of the text which satisfies that range
*/
/*
* fail command : on 'success' varible being false, run command
*/
/*
* success command : on 'success' varible being true, run command
*/
/*
* state name : changes the current state. This state change will change the GUI page.
*/
/*
* version input : tests to meake sure that the input is at least of that version, left to right.
* Ends if it finds one less than or greater than, but continues on equal. Fails on unequal input,
* including either a lesser number of wrong character (like '.' or '_' below)
*/
state FindJDK
/* Test Java JDK version */
run "%JAVA_HOME%/bin/java.exe" -version
test java version "\d+.\d+.\d+_\d+"\n
fail state DownloadJDK
success test d+.\d+.\d+_\d+
version 1.7.0_0
fail state DownloadJDK
state FindMaven
/* Test Maven version */
run mvn -v
/* ... */
If something like this is done, maintaining the process is simple. For example, making the JDK require at least version 1.8 would be as simple as changing the line ‘version 1.7.0_0’ to ‘version 1.8.0_0’. (although you would also need to change the DownloadJDK page’s text to say you need at least 1.8 as well). I actually love writing these kinds of things, and any input would be appreciated. This is just an unpolished idea after all.
Lastly, according to the Swing (Java) page, Swing is not written to be platform dependent like AWT, so at the very least, the application would be readable and usable on every OS, although it might not be perfectly formatted everywhere. As for automated tests, I have never done these to test a GUI interface (the file format above I could do), so unfortunately I am not sure how you would test these past running a Java program which shows a page and then you click a button to confirm whether it looks fine. Sorry.
I think it could be your MVP i.e. a standalone app, which guides you through the installation of JDK, maven, DB and command line SDK. Some could find it useful. It doesn’t even have to have a GUI (though I guess you could add one easily).
That special file seems like you are inventing your own programming language. I don’t find it more maintainable than Java code.
Having no automated tests would mean we need to test manually all workflows with every release and we simply do not have resources to do so. Once you add support for SDK commands beyond installation you will need automated tests.
My suggestion would be to limit the scope of this to be just an installer and see, if users find it useful. Definitely something doable in 7 weeks.
@mahovsven I do not see the need of a GUI since the focus of the SDK is for developers and integration with other tools such as Maven. Its faster to run it as a command line than use a GUI
After some discussion among group members, we have decided to instead work on UICM-66. Thanks @raff, @ssmusoke for your participation in the discussion.