OpenMRS Installer Project

Contents

Intern: Zach Elko Mentor: Dirk de Jagr Backup Mentor: Ben Wolfe

[edit]

Background

OpenMRS is a complex system that relies on various dependencies such as Java Runtime, MySQL, and Tomcat. The install process needs to be abstracted away from the classic installer paradigm which would instruct you that you don't have something you need, and display an error. The goal is to have an installer with a single point of entry that handles any dependency issues transparently behind the scenes. More so, if dependencies aren't needed, the installer should integrate into the current environment transparently as well.

[edit]

Goal

Make OpenMRS installation and upgrading a painless process for everyone, not just computer programmers.

[edit]

Use Cases

  1. An installer which only needs 1 point of entry by the user with any/all dependencies being installed transparently behind the scenes as to not distract the user
  2. An installer system which handles updates with ease, and skips unnecessary steps once it discovers that the system only needs updated
  3. An installer that won't interfere with previously installed dependency applications, and more so will be able to integrate directly into those applications in a transparent fashion
[edit]

Design

The design of the installer can be as complex as it needs to be, but the interface must be as simple as possible. I think this is the recipe for success. Any time you try to make something easy to use, you have to work 3x as hard to actually develop that piece of software. The OpenMRS installer is no different. There will likely be many technologies at work to accomplish this goal. These currently range from C++, Java, BASH, Windows BATCH, XML, and BitRock InstallBuilder cross platform installer. This list is sure to vary as time progresses and new challenges are overcome / encountered.

[edit]

Target Platforms

  1. Windows XP
  2. Windows Vista
[edit]

What Works

  1. OpenMRS installs completely on a fresh system with no dependencies installed
  2. The user can customize all aspects of the OpenMRS system at install time. This includes port numbers, database names, user account names, demo patient data, install location, and probably a number of other things. The goal is to have every customizable option available to the user at install time and I believe we are probably 90% there currently.
  3. A properties file is created to hold various options for the OpenMRS system
  4. Environment variables are used to direct OpenMRS to needed files and services
[edit]

What's Next

  1. Test the "smart" installer heavily. I believe most everything is in place, but there will certainly be some minor bugs to work out.
  2. Uninstaller. This is more complicated than it may seem, but we need to come to some agreement of what exactly will take place if someone wishes to uninstall OpenMRS. This will deal with a few things, but mainly the dependencies.
  3. Test both installers on Vista and address anything that may come up on that front.
  4. Begin work on making the installer aware of OpenMRS updates.
[edit]

Resources

Retrieved from "http://openmrs.org/wiki/OpenMRS_Installer_Project"