Alive...barely

Hello. Way too long since an update, let me get you up to speed...

School has been hell for this first month. Multiple schedule changes, annoying arguments with advisers/professors/secretaries, waiting around for distance courses to open up, submitting and resubmitting loan applications, etc etc etc. I've also been sick for going on a week now. The infection is beginning to go away (slowly) so by the end of the week I should be through it.

As some of you may have known, I was trying out for the BSU Bowling Team. I ended up making the team, so I'm excited about that. This doesn't really cut into my life too much, practice is only twice a week for about 3 hours, although I do bowl Friday and Saturday additionally.

The add/drop period is nearing for this term, so a lot of the annoying issues I'm dealing with will be out of the way regardless if I get them resolved or not. Hopefully then I can get back into a decent schedule of working on OpenMRS in some of my free time. I anticipate being able to get a lot of work done on some weekends when my other half goes back home to visit her family and work, so that should help me out a bit as far as scheduling is concerned.

So, I'm still here and my intentions are still the same. Expect some more iterations of the installer within the next few weeks. I look forward to getting them out there, that's for sure. Until then, take care.

Installer Progress Report

Hello, and happy Labor Day! I've been delayed in my "final post" due to a few reasons. First, I thought the deadline was Wednesday but it turned out to be Friday. Then, Friday I made my submission and worked with the guys a bit over a GoToMeeting session (very cool) to address some small issues with the installer, particularly the issues with Tomcat and environment variables. I spent the better half of the evening Friday addressing those issues, adding in the changes, and beginning to test them.

• We now create a net user account for OpenMRS, and this is the account that Tomcat is run as. This solves the issue of the environment variable because we will now copy the properties file to "C:\Documents And Settings\openmrs\Application Data\OpenMRS" where "openmrs" is the net user account we create. The WAR file knows to look here for the properties file, so prior to a reboot it will be able to locate it here in a hard coded fashion, and then after a reboot the updates to the environment variable will be visible to Tomcat and it can resolve the location from there.
• For now, you can no longer change the name of the webapp. This is sort of tied into the environment variable issue in that the naming convention for the properties file variable is that is should be prefixed with the webapp name. This is an issue because if the user does in fact change it to something other than "openmrs", then the WAR file can't find it.
• Due to bullet point one, there is no "Reboot Required" dialog since we are circumventing the environment variable issue.

The one last issue I'm having with this is that the password for the net user account isn't getting stored properly and Tomcat is failing to start under the rights of our newly created net user. I didn't get a change to get as far into this as I'd have liked to due some unexpected events over this holiday weekend, but after some testing I believe it may just be an error within BitRock or my script, rather than something more annoying relating to the actual service configuration. Once I get that ironed out I can upload another iteration of this installer.

Also, I've been working with BitRock to resolve a tiny bug in the dependency checking code. I've had 3-4 correspondences with them over the past 4 days, and we are trying to figure out why the bug is occuring. It deals with the drop-down boxes for selecting the MySQL / Tomcat installations the user would like to use for OpenMRS as detected by the dependency checker. Once the user selects one and then hits next, if they were to hit the "Back" button and drop the box down again, they'd see an additional 2 empty lines in the box. That isn't really holding me up much as I'm trying to complete these new additions /changes with respect to the webapp, environment variable, and net user account in the naive installer before diving back into the smart installer.

I hope to have an update for you within a few days, so until then take care!

Installer Progress Report

Hi again. It has been a while, for that I apologize. It seems the school year snuck up on me last Monday, and to say I wasn't prepared/aware of it would be a major understatement. This was a very hectic first week of school and I admittedly didn't get a whole lot accomplished. I feel more comfortable with that knowing that I will continue to contribute to my project well into the future; I'm not just leaving the people that hired me hanging in the wind. I did get some work accomplished tonight, however.

• I updated the C++ code that checks dependencies and it now checks for Tomcat. The mechanism for this is actually sort of neat. You see, BitRock has built-in actions to test for the existence/execute-ability of files. So, in the C++ code I simply obtain a list of directories located inside of the standard installation location for Apache Products. Then, for every directory that it finds there, I verify that it has the text "Tomcat" in it, and also that it contains a decimal point. I check for both of these items because they are tell tale signs that there is a standard Tomcat installation located there. From here, I parse out the version number from the directory name and compare it to the minimum version number required by OpenMRS. If it satisfies this, the C++ code logs that installation as valid. Here's the neat part: Inside of BitRock when it provides the user with a drop-down box of all valid Tomcat installs that were detected, it only displays those install locations that also have a /bin/tomcat6.exe OR /bin/tomcat5.exe. This sort of thing would have been really complicated to do in the C++ code, but with BitRock's built-in actions it's simple.
• As I was adding in the Tomcat checking, I noticed a bug in how I was handling version numbers with more than once decimal point. This is fairly common in software as there are major/minor releases. In the Math world, though, you can't make comparisons between 2 numbers unless they have a valid number of decimal points (0 or 1). The way I was handling this for MySQL was incorrect in that I was just assuming that by trimming the version at the last occurrence of the "." that I would be alright. That's all fine and well except for when there is only 1 decimal point... In that case, it was truncating it at the FIRST decimal point since find_first_of() and find_last_of() would point to the same location. I added in a simple 'if' statement to take care of that issue.

I'm currently waiting on a response from BitRock in regards to some advanced conditional evaluation logic that I need to implement. This is the code that is responsible for only displaying Tomcat installs that actually contain the tomcat5/tomcat6 binaries as opposed to just trusting that if the folder is there it's valid. The code I have in there is 90% correct, but the BitRock reference manual differs from the actual release so I'm having a tough time finding the "new" way of doing some of these things. They used to have a 'ruleGroup' in which you could group rules together and each would have their own 'ruleEvaluationLogic' being "and" or "or" but that seems to have since been removed. Once they get back to me on that, I will have enough of the dependency checking code completed that I'll feel satisfied using that in my final submission to my mentors.

I say "satisfied" because given the circumstances I've stated before, I believe I've really accomplished a lot. Not as much as I'd have liked to, but I can only look forward now. I've acknowledged my mistakes and I have already learned from them.

With that last bit of code in place, the heart of the dependency checking will actually be complete, only lacking in the testing area. Of course testing will reveal some small bugs, but the core code and logic is complete and in place. It will give me a very good base to work from during the upcoming future after the SoC program ends.

I'll make another post tomorrow after my final submission is complete and give an update on the project. I'm not sure how the updates will work once the program ends, but I feel it logical to continue to give the community updates on the installer project. Whether that happens through this blog or some other medium, I'm not yet sure.

Take care!

Self Evaluation

As we near the end of the SoC program, I thought it would be helpful to conduct a self-review of myself. I think this is important because you should be your own worst critic. Anybody that is great at anything is always hard on themselves to succeed, and to continue to improve. I'm no different.

A good example would be bowling. I'll go to the "Cosmic" bowling (dark, black lights, loud music, teenagers, etc...) because it's cheap and I can get a lot of practice in. Everyone else is there to "have fun". I'll be bowling next to people that are struggling to break 60 in their games, and then you have me...cursing up and down every time I leave a 10 pin standing, on my way to shooting a 190.

On with the evaluation...

• Dedication - OpenMRS definitely took priority over everything else this Summer, and I often found myself working on OpenMRS at all hours of the day/night, and every day of the week.
• Focus - This was my downfall at the start. When I got started, I was overwelmed with all of the different things that had to be accounted for in the installer. I chose to start developing some code for Linux, as that is my comfort zone. I figured it would be more beneficial to me to get code working in a familiar environment and then port it to Windows rather than start off on unfamiliar grounds. This did prove beneficial, but I lost a lot of time trying to build my bridge out of steel without first laying the foundation in floss. (Hi Paul. =] )
• Effort - I don't think I lacked in this at all. I gave this project all I had to give. This ties in to focus in that I was so concerned with everything working perfectly with the final grand scheme in mind that it hurt my progress a bit. I'd see potential problems with the temporary solutions to the point that I wouldn't even want to implement the temporary solutions. I wanted/want this installer to be as good as it can possibly be. I now know that consistent incremental progress is the only way to achieve this even if you will "waste" time with temporary solutions that get removed later. They help you understand the project better and assist your line of thought. It's not really a "waste" at all, but it may seem that way up front.
• Follow Through - Currently, if a user has a completely bare system, my installer fits the bill (give or take a few small issues that are being resolved). By the end of this week I'll have a better idea of how far my dependency checking version has to go, but I feel it's very close to on task, I just haven't done the full round of testing on it as of yet.

There are a few areas that I would have liked to have been better...

• I missed my release date a few times. I'm not one for excuses, so I'm not going to lay any on you here, but in software development, everything takes 5x longer than you probably initially planned for. Due to my lack of initial process due to lack of a focused plan, I had to play catch-up towards the end once I had my "floss" in place. This meant I was working on both the naive and smart installers at the same time, and addressing issues with both of them. This was a contributing factor in missing my release dates, but I felt/feel it was a necessary evil so that I could get the most production to the OpenMRS team for the money that I was paid.
• I guess I'll say it again: The lack of focus early on hurt the overall progress of the project. This was my first experience as a paid software engineer, so it was a lesson learned; an invaluable one at that.

Overall, I grade myself at a B-.


Once the term ends, my contribution to OpenMRS won't change much. I plan to continue working on the installer. This goes back to my dedication and effort. I want to give the team the product that they need, and that I was hired to give them. If they wish to offer me some sort of employment in the future, I'd be honored and I'd of course jump at the opportunity. Regardless, my work on the installer does not end on August 31st. I like to take any project I start through the finish, and I'm really close at this point. Not to mention the fact that I've become friends with a lot of members of the community. Friendships aren't on deadlines, that stuff is forever.

Installer Progress Report

Hello. Tonight I'm uploading a slight update to the naive installer. My mentors and I are still working on the issue with the runtime properties environment variable, and in parallel with that I've continued to make progress with merging the naive installer with the smart installer.

In my latest testing involving the environment variable issue, I've discovered the following things:

• Despite what some websites say online, all changes to environment variables made by BitRock (whether newly created variables or changes to established variables) are immediately reflected without a reboot.
• Tomcat does not seem to be able to access any new environment variables until after a reboot, despite Windows having refreshed them. The variables are being created/edited prior to anything else in the installer in terms of Tomcat, so that isn't the issue. Moreover, testing the existence of the environment variable in question AFTER the installation has completed and then restarting Tomcat yields the same result of failure to locate the variable.

Changelog

• Cleans up the post-install script to do away with some unnecessary variables that were being passed in. I had since changed the way those variables were used such that all work was done for them within BitRock instead of the post-install script.
• Addressed an issue in which I was incorrectly renaming the WAR file to take on the name specified for the webapp. There was apparently some miscommunication here when this was done, but no worries it's fixed now.
• Added a rename action within BitRock to place the WAR file into the webapps directory. We now no longer need to delete the WAR file in the post-install script
• I've added a "Reboot Required" screen into BitRock to account for the environment variable issue with Tomcat. This is hopefully only a temporary fix as we'd like to not require a reboot.

Issues

• Currently, you will have to reboot in order for the install to work.
• The post-install script is still going to try and launch the web browser to the OpenMRS webapp. I left this in for testing purposes so that you can see right away if Tomcat installed properly. If you see a Tomcat error message, then Tomcat installed fine. If you get a failed connection error from your browser, Tomcat didn't get installed/started: Let me know.

That should be it, let me know how it goes for you though. There will probably be a number of updates this week as we're getting into crunch time, so stay tuned, but keep the feedback coming!

http://openmrs.org/wiki/Special:Downloads/Releases/OpenMRS_Installer/OpenMRS-Installer-1.1.0-5.exe

Installer Progress Report

Hi. Been a while since my last update, I've had a hectic week. School starts up again on Monday, and I've had a lot of things to get organized as far as that is concerned in terms of class registration, loan applications, shifting money from checking/savings/credit/loans etc etc etc... Basically I hate this time of year with a passion because it's the most stressful, the most expensive, and the most busy. Anyways...

I'm going to be about a day late on my release this week due in part to the above reasons, but mainly due to the added complexity that adding dependency checking adds to the installer. I put in some good time tonight and am close to completing the puzzle.

• Now, the post-install script checks variables passed from BitRock to determine which actions to take in terms of installing the MySQL/Tomcat services, starting/stopping those services, resetting the MySQL password, and installing the JRE silently. I can't remember exactly *why* we can't run the JRE silent install from inside of BitRock, but I do remember that we can't. If I get time, this is on my list of things to investigate.
• I cleaned up some "/" vs "\" issues in the dependency code to make Windows happy.
• I cleaned up a lot of logic in the dependency checking BitRock code to properly handle some of the environment variables, as well as the PATH variable.
• As far as dialog screens are concerned, the dependency checking version matches that of the "naive" installer. I'm still holding off a bit on adding in the MySQL/Tomcat/War to cut down on build-times, but that will all come tomorrow after I sort out a few last bugs.

The other reason this release is delayed is due to a tiny bug we're having with the "naive" installer (although it would be an issue with the "smart" installer as well). The issue concerns Windows refreshing environment variables. This poses an issue when the user changes some of the default data, forcing OpenMRS to read the runtime properties files. The idea was that forcing a reboot would solve the issue, but in my efforts today, that wasn't the case. Rebooting refreshed the environment variable pointing to the runtime properties, but Tomcat still had an issue loading OpenMRS.

The guys have been out of town, so it's been a bit harder to get assistance with these issues due to our schedules, so hopefully when they get back IRC will be back in full swing and we can get this issue ironed out. In the meantime I'll continue to work on my dependency code. There are a few improvements that will probably have to wait until next week because they will involve major additions to the C++ code, but I'll have some version of the dependency checking code out within the next day or so.

Stay tuned!

Another day, Another Installer Release

Hi folks. I had a super-productive day today during my visit to OpenMRS headquarters in Indianapolis. Below you'll find a changelog for this release and the link for the download (eventually).

• Added Start Menu link to the OpenMRS website
• Fixed the custom Tomcat port issue. Now, whichever port you specify will be the port used when launching the browser
• Added support for changing the webapp name (the name that Tomcat uses to identify OpenMRS)
• Added option to allow/disallow loading of modules through the webapp
• Fixed the custom OpenMRS database name issue. Now, if you specify a different name for the OpenMRS database (not the default 'openmrs'), this change will actually be respected.
• Added option to change the MySQL OpenMRS account (only used internally). Previously if you changed it, it would ignore you. Sorry.
• Full support for the runtime properties file. Up to this point we weren't using it at all. Now, every relevant option is reflected in the runtime properties file such as MySQL username/password/port/database name, boolean module upload, etc...
• Fixed the top-right logo that was out of proportion. Thanks Ben.
• Tomcat is now installed as an automatic service instead of a manual service.
  

If you tried out my previous installer, follow these steps to obtain a "clean" system to test this one.

• Open a command prompt - Start, Run, "cmd"
• net stop mysql
• sc delete mysql
• net stop "apache tomcat"
• sc delete "tomcat6"

That will stop both MySQL and Tomcat, as well as delete them as Windows Services. Those are the main testing points for the installer as the silent Java install never fails, so don't worry about it. It may also be a good idea to delete the previous installation directory after executing those commands. If you try to do it before hand, chances are MySQL and/or Tomcat will still be running and it will fail.

I think that's about it. A few issues to keep in mind...

• Somtimes, for no reason at all (most likely a timing issue), Tomcat does not get installed as a service. This will cause the net start "apache tomcat" command to fail, clearly, since it hasn't been registered as a service. I'm working on this, but it's random and it I'm nearing cluelessness on this one...
• Again, sometimes the MySQL database does not get created. I'm confident this is a timing issue because it only happens for me when I'm at home on my laggy VMware image. Today at OpenMRS HQ, the only thing that gave me trouble was the occasional failed Tomcat Service install. The MySQL worked every single time
• Sometimes, the browser will launch prior to Tomcat finishing starting. In this case you will see an error that you can't connect. Wait a few minutes and refresh the screen. If you continue to get the unable to connect error, Tomcat probably never installed as a service and thus didn't start. If you see a Tomcat error page stating that OpenMRS could not be loaded, this means that the MySQL database wasn't created. Let me know either way and I'll help you out.
  

If you encounter either one of these issues, please let me know. I'll have you up and running with very little effort. If you encounter any other issues, or you have suggestions, please let me know those as well. Thanks!

http://resources.openmrs.org/OpenMRS-1.0-windows-installer.exe

Installer Release

Yay! I got it to work! Here were the major issues holding my progress up:

• Timing of commands - When you execute commands in a script as opposed to on the command line, the behavior is completely different. The operating system essentially goes down the list of commands and spawns each one off. If a command takes longer to execute than you may expect, and your next command depends on the previous one: disaster. Normally you would fight this using the built-in 'start /wait ' mechanism, but the nature of how Bitrock executes post-install scripts really hinders this because sometimes the installer will just hang if you use the /wait switch. Couple this with the fact that Windows XP doesn't have a 'wait' or a 'sleep' command, and you've got yourself a headache. To fix this issue, I started the MySQL server first, then I did the silent install of Java to kill some time, and THEN I reset the root password for MySQL. That handled the timing, and fixed the SQL script issue.
• Behavior of 'service.bat' - This script is provided with Tomcat for a simple way to install Tomcat as a Windows Service. The problem is, if you call it from within a script, nothing else in your script will get executed after 'service.bat' finishes. No combination of switches can save you here, the reason being is that while you may say '/wait', 'startup.bat' executes a number of other commands that don't use that method of execution. So, instead of calling 'startup.bat' as part of the post-install script, I call it from within Bitrock prior to the execution of the post-install script, and then I simply start the Tomcat service in the script.
• Build times - As I've stated before, this really killed me. Any change I wanted to implement and test would take a total of 15 minutes before I would know if it worked or not. That's a lot of time lost, especially considering the hit-or-miss nature of the testing environment due to the issues I listed above. Something will behave one way locally in the script, but how it behaves in Bitrock is entirely different.
  

Well, those are a summary of the issues. I bottled them up nicely and it only seems like 3 things, but there are a number of painful individual things within each of them.

Installation Tips

• This installer assumes you have none of the dependencies. Please make sure this is the case. No JRE, No Tomcat, and No MySQL.
• At the MySQL Information screen, the dialog is a bit misleading. These will be cleaned up, but for now just know that the username MUST be 'root'. The password can be whatever you want it to be.
• At the Tomcat Information screen, the dialog is on task, but to be safe and sure that you are experiencing the same installer that I did, leave the username as 'admin'. It shouldn't matter, but I can't recall how I setup the tomcat-users.xml file just now, so I make no guarantees. (Although, this would be good info for your bug report feedback).
• When the installer tells you that it's executing the final installation script, be patient. It will take a relatively long time, but trust me, it does finish. You may see an error box pop-up that says something about "Error sending parameters to program..." and it will display the URL for the OpenMRS system. I'm not sure why this comes up, but just hit "OK" A browser should pop-up and display the OpenMRS system. You may have to refresh it, but probably not. Once the script finishes, you'll have the option of displaying a Readme, and then you'll be done.
• The installer currently places Tomcat and MySQL inside of the installation directory. This is not permanent, but I have some issues to work out involving the dependency checking and setting path/environment variables accordingly, so that's why I'm not placing them in their proper locations just yet.
  

Strange Behavior

• As seems to be par for the course, sometimes the script doesn't execute properly for seemingly no reason at all. If this is the case, you'll probably get an error saying the script didn't execute successfully, and you'll see an error page for Tomcat. For example, I just ran a new build of the installer that had no effect on the SQL scripts, but for some reason all of the SQL scripts failed saying that they couldn't find the "openmrs" database. I ran the SQL scripts manually, and guess what? No errors, I restarted Tomcat, and the system was fine. It honestly and truly makes no sense. There must be some strange timing issues going on, and I just don't have the time to waste fixing them right now. Let me know if you have this issue and I can get you up and running very easily. All you need to do is finish the installer (not cancel it), and then run the SQL scripts located in ${installdir}/model (where ${installdir} is the location you chose to install OpenMRS). You'll have to follow the instructions from the website on how to execute those scripts (if this becomes a widespread issue I'll type up an updated tutorial), but once you do, simply restart Tomcat and you're good to go. I'm not going to ignore this issue, I just need to focus on other elements of the installer currently; this isn't something that fails every time. I think the issue for me is that my Vmware image runs very slowly. Given that, if the createdb script doesn't finish in time, then the rest of the scripts will fail. I'm almost entirely certain that's what happened in my last run. I'd have to do some string modification to alter the SQL script commands to be executed using the 'start /wait' mechanism, but once that was in place it would solve the issue.

Update
I decided to re-run the first working version that I had tonight. This is a version that worked with no problems at all the first time I ran it. Guess what happened when I ran it this time? It never created the database. This version never had that issue, only the newer one did. This just goes to show you the ridiculousness I've been dealing with. It seems that it randomly just doesn't create the openmrs database. In fact, in other occasions outside of Bitrock, I've gotten strange SQL errors saying that certain "concepts" didn't exist. I think there is some sort of bug behind the scenes with MySQL or these scripts. I'm not losing my mind, I know for a FACT that the version I've uploaded worked on a bare system. I reset my VM, and surprise! It didn't work. Regardless, with the version I put up (the first working version), if you get a Tomcat error saying it can't find OpenMRS, just run the SQL scripts manually and restart Tomcat.

By the way, I decided to not upload the "newer" build. The one thing the newer build fixed was it made Tomcat's service "auto" start. So, for this build you'll have to change that start type in "Settings, Control Panel, Admin Tools, Services, Right-Click on Apache Tomcat, Properties, Startup, Auto".


Please let me know of any issues/bugs/suggestions you may have. Thanks!

resources.openmrs.org/OpenMRS-1.0-installer.exe

Installer Progress Report

Wow. About 6 hours ago I thought I was ready to release. Then everything fell apart on me. By everything, I mean one single line in a 12 line BATCH script. Since that time I've been debugging myself to death over this thing, and it's been rough for a few reasons...

• Vmware is sluggish as hell
• 5 minute build times
• 3 minute copy times to put the installer in the Vmware image
• 5 minute install times
• Different results when BitRock runs the post-install script than when you run it manually
• Timing issues with commands, and how Bitrock handles that (all black box...)
• When I address the timing issues using /w and/or /b, Bitrock will sit forever waiting for an application to exit that is in the background somewhere

I've got the situation narrowed down, and I know exactly what line is "failing". Bitrock is passing in a mis-quoted variable that points to a path. When I try to reset the root password in the script, it fails because of that mis-quoted variable. Thus, none of the SQL scripts get executed because of bad credentials. I spent hours debugging the BATCH script and running it manually, and I got the system running each and every time. So, believe me, the installer works on a bare system, all of my code is absolutely correct. I had issues with Bitrock's variable passing (how they handle spaces as opposed to how BATCH handles them) before, but this time the normal fix isn't cutting it. Combine that with the fact that half of the time I never see the post-install script result, I never see what command it's trying to execute. I have fixed that now, but it's 5:30am and I absolutely have to go to sleep. Once I get the variable into shape, everything will work just as flawlessly as it does when I run the script manually with data that I've fed it. IT WORKS! I PROMISE! You'll soon see it for yourself!

Yep, I've lost my mind. Goodni..morning.

Installer Progress Report

Hello again. Well, I got cracking with Vmware this evening, and I have ironed out a few of the bugs with the "naive" installer.

• When loading the MySQL package silently, some trickery is needed to set the root password since it is initially blank. This requires starting the MySQL server with the --skip-grant-tables (probably not exactly right, but that's the command in general) and then setting the password. After this process, the MySQL server needs to be restarted with the normal options prior to running the OpenMRS SQL scripts. This is something that I had missed earlier. Luckily, you can do process management on the command line with Windows XP; I never knew this. So, I added a "tskill mysqld" line to the BATCH file, and that problem is solved. I then found that the MySQL service was actually being installed properly via the BATCH file.
• There were some hacky environment variable settings in use for this naive installer because at the time I added these features I was working on my production system on-site. Given that, I didn't want to un-install Java just to find out where the silent Java install was going to place the JRE (for use in setting the PATH variable, and the JRE_HOME variable for Tomcat's startup.bat). So, on-site I just hard coded the location of the current Java installation. This would explain why it wasn't working for Paul when he tested it, or myself in my Vmware image. I fixed that in terms of Java, but for some reason the environment variable for Tomcat doesn't seem to be taking effect.

Those are the 2 major things I was able to correct tonight. It took me a while to get the whole Vmware system up and running so I could take a decent snapshot of it. An important lesson I learned was to copy the installer exe from your primary source (flash drive/host operating system) to the Vmware image prior to running it. Otherwise, very strange things occurred with the file paths in Bitrock and there was an error generated, although the script seemed to execute fine.

The current issue is with Tomcat. For some reason it is requiring a JDK instead of just a JRE. My understanding up to this point was that OpenMRS only required the JRE... As I did some reading I learned that from Tomcat 5.X and up, Tomcat only requires a JRE and that you could set both JRE_HOME and JAVA_HOME to the location of a JRE's bin folder. This is contrary to the error startup.bat gives stating that JAVA_HOME must be set to a JDK and not a JRE. Feeling hopeful, I tried this, but it failed. If JDK is required instead of just a JRE, that changes things. A lot. The dependency checking code would have to be updated to search for the JDK command, which I believe is just "javac". Luckily the JDK bundles a JRE with it, so as long as the JDK was up to date, we could safely assume that the JRE was up to date as well. I would have to change the installer exe for the Java dependency to be that of the JDK instead of the JRE.

Once I get these questions answered, I'll move forward and get the Tomcat service issue fixed, and you guys will have a release of the "naive" installer tomorrow (Saturday). My goal is to release the dependency checking version on Sunday, but my mother has decided to come to town on Sunday, so it may be Monday depending on how well things go tomorrow with the "naive" installer.

As always I'll keep you updated. Thanks.

Installer Progress Report

Hello. Well, I'm a bit short of my Thursday deadline. Due to some communication breakdown, I didn't receive any feedback on my previous week's installer which suffered from some Windows Service issues. Throughout this week, I focused on implementing the communication between BitRock and the dependency checking. I'm happy to say, that portion is working very well. Between my long hours last night, and today, the installer is very close to completion. However, there are a few kinks to work out; mainly the Windows Service issues. Below is a summary of the new features I've got implemented:

• MySQL / Java Dependency Checking - The installer is now aware of these dependencies. If you have multiple MySQL installations, it allows you to choose which one you'd like to use for OpenMRS. If you don't have them, it presents you with a screen informing you of this, and asking if you'd like to specify the location to the dependency (maybe you have it installed in a custom location), or if you want the installer to load the dependency for you
• User-Specified Dependency Validation - Since the installer allows the user to specify the location of all of the dependencies, I built in vaidation rules that verify the dependency exists where the user says it exists. It asks for the location to that particular dependencies binary, and then validates that it actually exists.
• Smart Environment Variables - Depending on how the dependencies are installed (i.e they were detected, they were specified, they were loaded by the installer), the environment variables are handled accordingly using the given path.
• Windows Services - This is a work in progress, but in my current installer I've implemented the code to create and start Windows Services for MySQL and Tomcat, provided that the user does not already have those dependencies installed. It's all very dynamic now that the dependency checking is in place because only things that need to happen, happen. I think this bullet point here will go a long way towards fixing the current "full" installer.

I've merged the "naive" installer with this current one with the exception of all of the bundled files. The reason is, with all of those files bundled in, it takes 5 minutes to build the installer every time I make a change, and then it takes 5 minutes to unpack those files during the installation (provided they need unpacked). Tonight, I put Vmware on my machine, and have started loading an XP image in it. This will simplify the process for me this weekend as I try to get the Windows Service issues fixed. My original thought was that they were failing due to not having an "empty" system in terms of dependencies, but I just found out tonight that's not the case. I do however feel strongly that using BitRock to install/start the services will fix a lot of issues, as opposed to executing awkward commands in a BATCH script.

There absolutely will be a release (or multiple) before the end of the weekend. I've been re-prioritized in that Paul wants the Windows Services fixed on the "naive" installer before I handle the dependencies, although the dependency work is in place and complete. So, I'll fight that battle tomorrow once Vmware is finished, and once the Windows Service issues are fixed, I'll release that. Then, I'll iron out a few things with the "smart" installer and release that as well. Promise.

This has been the most productive week by far, and it's really exciting. I have a kit things to show everyone, but Paul is adamant that he see the installer work on an "empty" system before he sees anything else, and I don't want to put out a release that doesn't get the system up and running just for the sake of showing off all of the cool features I've added. So please, bear with me on the slight delay and I'll update everyone tomorrow after the Vmware adventure. Thanks.

Installer Progress Report

Hello. It's been a few days since my last update. I've made some good progress, and I'm on track for my Thursday release with the goals I've set for myself. The main focus of this release will be to incorporate the dependency checking to some degree so that only missing dependencies are installed. With this eventually will come germane dialog screens that inform the user of which dependencies were located (multiple MySQl/Tomcat/etc), and giving them the choice of which one to use, or to specify another one all together. At the very least this release will be able to detect MySQL and Java and proceed as necessary. I'd also like to implement the dialog logic so that the user can select which MySQL install to use, and actually that is fairly easy. Today I broke a lot of ground in way of achieving that goal, actually.

• Screen Logic - I've got all of the dialog logic working so that I'm in full control of which screens get displayed to the user based on the value of any variable of my choice.
• Dynamic Selection - With the help of BitRock support, I've figured out how to populate a drop-down selection menu with variable data representing valid dependency installs (i.e multiple MySQL installations).
• Dynamic Components - Using similar logic to that of the screen control, I can now control which components of the OpenMRS system are actually installed. We bundle all of the depends with the installer, but depending on the result of the dependency check, only the needed ones are ever unpacked (installed) during the install process.

It may only be "three" things, but those three items are huge milestones in the installer. In fact, those three elements are the cornerstone to the dependency checking interface into BitRock; this is the stuff that makes the installer worth it's weight in gold. I'll hit it hard tomorrow evening and transition into Thursday morning preparing for my evening release. By then, I anticipate a lot of progress in a few other small areas such as:

• Moving any dependencies we install to a standard location
• Cleaning up the install folder after installation, not leaving behind any unnecessary files
• Clean up the environment variable exporting so that it is determined by the information that the dependency checker determines or that the user selects.

I'll keep everyone updated, take care.

OpenMRS Visit #2

Well, today I made my second visit to OpenMRS headquarters in Indianapolis. As usual, it was great to see the guys, but also great to be in a professional software development environment. The OpenMRS guys are truly bright individuals, and it's more apparent in person listening to them problem solve and go back and forth with each other trading solutions. While I did get a lot of work done today, there are still a few hangups that I'm trying to iron out. When I do so, I'll have a much improved beta-installer for you all to try out.

Just a little insight into how I work... The beta's I try to get ready for the weekly releases are 1 of maybe up to 3 different installers I'm working on. When I say "different" I mean, they all contain subsets of more advanced functionality that will eventually be part of the final product. I'm currently working on 2 major installers: First, an installer that is ignorant of the environment, but does silent installations of all of the dependencies and configures them silently as well given the data input during the BitRock installer. Second, I'm furthering the development on the dependency checking code and working that into a stripped down installer for testing purposes. Once the dependency checking is "complete" I'll then merge that into the "ignorant" installer, and everything will just mesh due to some logic rules within BitRock that determine what gets executed when, and why. So, while the next update (coming before Sunday) will only be a marginal improvement upon the last (actually, it's a huge improvement), it is only a subset of the work that I've actually completed.

The "delay" with the dependency checking came in that after the last beta was finished, I started programming the dependency checker. Then, yesterday I found out that the mechanism I'd hoped to use to read my dependency checking program's output wasn't going to work, and I had to find a new method. This was also in parallel with having to get some sort of demo ready for my visit today. So, it's been hectic going back and forth between the two installers while always trying to make progress in both areas, but it's really starting to come together. The source code for the dependency checking is essentially complete, and any little things that come up are easily added/modified since it's C++ and I have full control of what I do. As for getting that data into BitRock, I had started experimenting with that yesterday, but ran into some confusing issues. However, after my work today, I have a much better understanding of how to address those issues.

The current updated installer that I'll have out to everyone within the next day or so includes the following upgrades from the previous installer:

• Multi-Input Dialog Screens - You can now enter all relevant data on one screen instead of 4 or 5
• Silent installations of all dependency applications - I use command line switches for the JRE installer, and I've bundled zipped versions of MySQL and Tomcat with the installer. They are unpacked into their proper places, and then I use BitRock's file editing abilities to configure their settings files with the proper data (username/password/port/etc...)
• Setting of needed environment variables - Certain env variables need to be set, such as the path to the JRE, CATALINA_HOME, etc... as well as adding MySQL to the path after it is installed.
• Demo Data - You now have the option to forgo installation of the demo patient data. This is helpful for people that already have OpenMRS running, and just need to install it on another system.
• Port Validation - The installer now verifies that it can bind an address to the port numbers you specify for MySQL and Tomcat. If not, it asks you to enter a new port.
• Improved Error Detection - The installer now correctly enforces illegal empty data (i.e all of the input data during the installation process)

I think that's about it as far as the changelog is concerned. The current hangups both deal with adding MySQL and Tomcat as Windows Services. I got nothing but grief today when I tried to do this, such as error messages that didn't tell me why it failed... This was the main reason I didn't have a demo to show the guys today, and that really bothered me. I wanted to show them what I had done, and I suppose they can still see everything except for it successfully starting the system, but still... very frustrating, for everyone I'm sure. I think the issue may have been linked with the fact that the machine I was using already had MySQL and Tomcat installed as services, but I didn't want to wreck my development machine with a scavenger hunt that may have turned up nothing.

That's all for now, I'll get the update out as soon as possible. I've worked myself thin the past 3 days, even to the point I had to stay home from my other job due to illness, so I've got to step away from it for tonight and put in a LONG weekend of work and get this thing finished as soon as possible. I'll keep everyone updated, thanks.

Installer Progress Report

Alright, today was a relatively productive day.

• First, the dependency code now detects MySQL in the PATH as well as those not in the PATH but in standard install locations. The issue now is avoiding duplicates, and this won't be easy to handle. You see, on UNIX, the 'which' command tells you the full path that is resolved when you execute a certain command. Windows (by my searching) has no such command. This presents a situation in that we don't know which installation the binary located in the PATH points to. It could point to the only installation they have on their system, or it could point to 1 of any number of installations; we just simply don't know. The only real way to do this is if we find a MySQL located in the PATH AND we found an installation in a default location, we then have to check the PATH variable for the presence of any/all of the default install paths that we found. Just the thought of that program logic scares the crap out of me. Again, 90% of my thought/worry/planning/nightmares account for maybe 10% AT MOST of the end-user use-cases.

• Moving on... The installer now supports the choice of installing the demo patient data, or not. The user is presented with a dialog, and based on the answer, the sql script responsible for loading the demo data is either executed or not.

• I also cleaned up the organization of files, both for my own sanity, and for the cleanliness of the install. The next step in this area is adding in the code to clean up after the installation, removing files that aren't needed. I'm not sure there will be a large amount of those, aside from any dependencies that weren't needed (plus the Java installer exe), and maybe the sql scripts, but I can foresee it being helpful if the users had those on hand. I'll just have to poll the "suits" about what they think. A comforting discovery I made while looking into this tonight is that Windows does support a file moving itself to a new location (i.e a BATCH script that moves itself to another location as its last instruction). It also supports self-deletion as well. Given those two, this is a trivial feature to implement once I know what needs to go, or what needs to go where.

Well, I think that's about it for now. I also had a talk with Ben about the MySQL credentials that need to be addressed in the installer, so I have a better grip on that now. The key next few steps in the installer process are:

1. Detect Tomcat - More difficult than the other 2 dependencies.
2. MySQL Creds - Make sure all needed info is asked for, and presented in a clear fashion.
3. Runtime Properties - This goes hand in hand with #2, and somewhat with the dependency checking.

Alright, I'll keep you guys updated. Take care.

Installer Progress Report

Hello all. I took the weekend off for the most part due to a friend visiting from out of town, but tonight I really dove into the dependency checking code some more.

The code is written in C++ in order to break our dependency on the JRE at install time. This makes things very challenging from a programming perspective because C++ has no built-in way of getting feedback from system() commands. That was the nice thing about Java; all of that stuff was built-in. The only way (that I can see) to do it in C++ is to append " > somefile.txt" to the end of any system() command you want to run, and then read that output file. It's a pain, yes, but it does work, and actually pretty well for what I need it to do.

Anyways, currently the code can detect the JRE version and multiple standard-install MySQL versions. "standard-install" is defined as "Installations located in the standard MySQL install folder: C:\Program Files\MySQL" The way it does this is it obtains a list of all files in the standard install directory, and knowing the directory structure, tries to find a MySQL binary in the bin directory. It then logs each valid install to a file that BitRock will read during installation. If no valid installs are found, it logs a single failure. The same goes for the JRE, except it only checks for the standard JRE which is installed to the PATH by default.

My main goal for tomorrow is to support MySQL that is installed in the PATH. I started to do this tonight, but it became really complicated to search for MySQL in the PATH AND multiple default installs. The main reason is that we need to keep track of the path to each valid install so that BitRock has that information to provide to the user so they can choose which installation of MySQL they'd like to use (if they have more than one). I think I've got a better idea of how I can implement this now that the code is more or less complete, so we'll see how that goes. My other goal is to interface this code with BitRock. This will consist of using BitRocks readFile mechanism and parsing the log file that my dependency code generates. Depending on how easily I get that accomplished, I could start taking action on that information and then displaying the proper screens to the user. Although, I think that will come on Wednesday at the earliest.

I'll keep everyone posted, take care.

Installer Status Update

Hi everyone. Well, the past few days have been very productive and very exciting. A lot of tricky hangups have begun to get resolved. First, I'd like to comment on the installer that is already out there.

On my system, the dependency installers wait for the previous one to finish prior to launching. When I tried to create an updated build of the installer yesterday, this was not the case. In fact, the behavior was very sporadic; sometimes there was a bit of a delay, other times they were all spawned at once. If you run into this issue with the installer, you will most likely have to go through all of the needed installers when they come up, but then run the installer a second time, but cancel the installers then. Otherwise, if you didn't have MySQL / Tomcat, the installation couldn't possibly be successful, etc...

I have opted to not fix this issue for a few reasons. Mainly, once the dependency checking is in place, the installation of these applications will happen in a completely different fashion. I've obtained "binary" zipped versions of MySQL and Tomcat, and those dependencies will happen in that fashion. Java will be the only dependency that uses a setup exe, but that is easily handled silently with command-line switches.

So, my focus now will be getting the dependency checking to a good beta maturity so that the rest of the installer can come together. One nice thing I have found out how to do is multi-input dialogs. This means you'll have one dialog to enter all of your MySQL information, and then another dialog for all of your Tomcat information, and etc... for any other data we may need to obtain in the future. This is a big improvement upon the current version in that there is only one input per screen.

My goal is to have some sort of updated installer every week, ideally on Thursday or Friday evening, but I may change this to Sunday to allow me to have some extra cram time during the weekend to complete some work. This week the "update" came on Tuesday, and you would have had another one last night, but due to those issues I touched on earlier, I didn't want to send out a horribly broken installer. I'd really like to know why it decided to behave completely differently this time, but oh well.

So, plan on an updated installer by next Sunday at the latest, next Thursday at the earliest. Until then, take care.

Installer Beta

Greetings! I put in a 10 hour work day today, and I've got a beta-installer working. It does essentially what the current izpack installer does (although the version a lot of you/us were trying to use was broke, you may not have seen it). As I said before I've been focused on handling dependencies or I would have had this beta out a lot sooner. A couple of notes on the beta:

1. It's a beta. I don't recommend running this on a system with any sort of working OpenMRS installation. The reason is that the installer will drop the 'openmrs' database if it exists. I have done next to nothing with the actual OpenMRS system, so I'm not sure what you all may be doing with it, but you've been warned, 'openmrs' gets dropped and re-created with the demo data contained in the sql scripts on the website. Also, if you have Tomcat running, you MUST stop it prior to running the installer. You can "Cancel" the Tomcat install later, but you must make sure Tomcat isn't running.

2. During the install you will be asked for various pieces of information such as: MySQL Username, MySQL Password, MySQL Port, MySQL database name to use, Tomcat Username, and finally the Tomcat Password. Currently, I don't have silent installs of the dependencies implemented; there are a lot of things to address in that regard and it may not turn out to be possible with the way we are currently doing things. Because of this, you will have to enter this data twice. Once in the BitRock install portion, and then again when BitRock launches the dependency installers. If this data doesn't match, it won't work obviously. If you happen to already have these dependencies installed, be sure to provide BitRock with the usernames/passwords/ports that you are currently using and of course "Cancel" out of the dependency installations when they get launched.

3. More so, if you already have any of the dependency applications installed, feel free to hit "Cancel" when that particular installer gets launched at the end. HOWEVER, if you "Cancel" the MySQL installer, you need to make sure that mysql.exe is in your path.

4. Following with that, if you DON'T hit cancel on the installers, the only one that you need to do anything special for is the MySQL installer. The instructions for that installer are as follows:

• Select "Typical Install"
• Skip Sign-Up
• "Configure Server Now"
• "Standard Configuration"
• "Install As Windows Service" AND "Launch Automatically" AND "Include In Path"
• "Modify" but do not allow remote access

Note: If you choose to uninstall MySQL prior to running this installer, you MUST delete the C:\Program Files\ entry for MySQL. Otherwise, it won't accept the username/password you provide during the MySQL installation. Basically, if you want to let the installer load MySQL, uninstall your copy and delete it's program folder. Then, use BitRock to set a username/password and then give that same data to the MySQL installer that gets launched at the end of the installation process.

5. There will be a slight bit of lag/delay as the installer executes all of the sql scripts and deploys the .war file. This is normal. What you will see is a long pause, then a browser will launch and connect to the OpenMRS installation. Then, a script output box will appear. You can just hit "OK", and then the installation will ask you to view the README, and you'll be done.

6. If you get an "out of sync" error when you try to view the installation, you'll need to restart Tomcat. This probably means you didn't read step #1... but I ran into this when I manually dropped the 'openmrs' database and then ran the installer without ever restarting Tomcat.

The whole process is actually really simple, although it may "sound" complicated. The goal of this beta was to install all OpenMRS and all of its dependencies on a completely bare system. However, in my own testing, I commented out the lines that launched the dependency installers since I already had them, so I know that this method does work as well. However, you just need to be aware of the issues I mentioned above when choosing to forgo the dependency installations in light of using your own.

Your feedback is welcomed, but please keep in mind this is a beta, and a lot of the issues will be fixed in the upcoming days/week. Dependency awareness is the next big step for the installer and that alone will solve 80% of the issues. Thanks!

Download

http://resources.openmrs.org/OpenMRS-Installer-Beta.exe

Installer Update

Hello. After my meeting with the OpenMRS guys on Thursday, I was given some milestones to hit. You see, when I first started working on the project, my first plan of action was to improve upon what my mentor had already created. The major downfall of his work thus far was that it wasn't cognizant of the environment in terms of dependency applications. Actually, the installer failed if you had any of the dependencies installed. So, my main focus was 1. How to detect dependencies on Windows/Linux/OSX and 2. How to go about loading them. During this time, I was exposed to many different install builder options. It was at this point I began to look for something other than izpack to build the installer out of nothing more than curiosity if there may be something better.

Anyways, the point is that the BitRock installer that I demoed for the guys didn't do a whole lot. The interface that the user will see was pretty much set in stone, but behind the scenes not much actually got done in terms of installing anything. The reason for this was that I wanted to leave out all the easy stuff, such as launching dependency installers, running the sql scripts, etc... so that I could quickly test the installer while I was learning how to do the more advanced things such as edit files, interact with outside programs, etc. I knew how to do all of the easy stuff, but I just wanted to keep it out of the code until I had the hard stuff handled. Tonight I've achieved 85% of my imposed milestone for this week.

My BitRock installer now launches all dependency applications once it collects any necessary information from the user, such as the MySQL user name (either one they want to use, or the one they are currently using if they already have MySQl), MySQL password, MySQl port, etc... From here, I've been able to take advantage of BitRock's variable system to pass this information to a post-install script so that I can have access to these pieces of data when executing the dependency installers, the sql script, etc... This is a big step because these were some major issues to address. The main reason those variables are important is because they can aid me in performing silent installations of the dependency applications by passing them to said installers as command line arguments.

Once I get that achieved, the next step is to go back to dependency checking so that we are only installing what we need to install. I'm awaiting word back from BitRock in hopes to gain an understanding of the capabilities of their installer in terms of launching external applications during the install process at specified points and then continuing the installer process once those applications have completed. This will enable me to write my dependency checking code and then call it from within the BitRock installer. My application will pass some information back to BitRock (probably by writing to a file), and then BitRock will be aware of what dependencies need to be loaded.

Well, that's where I stand today. Hope this post was relatively easy to follow, I'm sort of scatterbrained at the moment! Take care, enjoy your weekend.

OpenMRS Community

I'd like to talk a little bit about the OpenMRS community because it is just that; A Community. From the first day I joined the OpenMRS chat room on IRC, I started to make friends with the other hopeful students, as well as the mentors.

The funny thing was, after the SoC dust had cleared and we all found out who was in, and who was out, those friendships didn't change. In fact, one student that wasn't accepted (well, he was, but he was accepted elsewhere as well) is still active in the channel daily! We're all still friends, on IRC, on Facebook, on AIM, and if we lived closer, in person as well.

The great thing about it is, we aren't just friends in terms of programming/working on OpenMRS. We are friends for social reasons. I'd say the conversations that take place between all of us, even the mentors, is 50% OpenMRS and 50% life. The mentors have been a great resource for me personally, not just in terms of my project, but for everything. They are grown adults and if I ever have some obscure life question regarding credit cards, bills, taxes, black magic, etc... I can always ask one of them and get a great answer.

To me, this is the definition of a community. OpenMRS is composed of a lot of different types of people all sharing some very similar, and also very different characteristics and skills. Given this, they are all working together towards a common goal, but at the same time have built a social community that will stand the test of time.

Typical Working Environment

I thought it may be helpful for some people to understand what a typical development session would look like if you were to peek over my shoulder. I'll give you a quick rundown of the myriad of applications/websites/editors/etc that I have open at any time during a development session.

1. Firefox

• Java API - A must!
  
• Gmail Inbox - I like to stay on top of e-mail
  
• BitRock Documentation - To make sure I don't re-invent the wheel...
  
• Various example websites - Sometimes an example is worth a thousand words
  

2. NetBeans

• I usually have a few projects open, some being test classes, others my full blown GUI's
  

3. Visual Studio

• This is only used for my XML editing; it does a nice job. Although I could probably do this with NetBeans?
  

4. BitRock Install Builder

• Sometimes I'll close this if I'm not working on the installer XML file, but it's been open a lot lately.
  

5. Xchat

• #java - Always good to idle and ask questions
• #openmrs - Duh...
  

6. Console

• Although NetBeans does a fine job of executing code, I like to enter the commands myself a lot of times because often I'll have to deal with files in nearby directories and what not, and I just find it a bit more efficient to do it all in one place. I do the same thing on Linux in that I'll code in NetBeans and then compile/run in the console window.

Well, that about does it. It can get very "busy" on my screen, maybe I can use some of this SoC money to grab another monitor and dual-screen it... :)

Mid-Term Update

Well, the week of the mid-term is upon us. Ironically, this is when everything has been coming together for the installer. I now have a clear view of how all the different elements of the installer will work together, and the specific obstacles still to overcome. Solutions have been found for a number of previous obstacles, some just on paper, others have begun to be implemented. Please note that this is focused on the Windows installer, the Linux installer is a separate goal and it will be addressed either once the Windows installer is fairly functional, or sometime soon after SoC has ended. Here is a brief TODO in no particular order:

1. Figure out why the BitRock glob file pattern isn't working. This will enable me to configure the users Runtime Properties file. If you have experience in this, please help! Here is a link showing what I'm trying to do as-per the BitRock documentation:

http://bitrock.com/support_installbuilder_faq.html#A8_1

The part to pay attention to is the "files" tag. The way this works is depending on where that entire chunk of XML code is placed in the project's XML file, the root directory is implied. So, for me, I've got a similar chunk of code to that located in the section that handles files in the install directory; in our case C:\Program Files\openmrs. Now, I simply need to substitute text in 1 file in that directory, and I know exactly what the filename is. Hence, I don't need to worry about all of those wild cards and whatnot. I've tried everything imaginable, and it's not working. The file I'm testing this with is located in:

C:\Program Files\openmrs\temp\testFile.txt

So, given that, if anyone knows the glob file pattern to edit just that file, I welcome your help!

2. Handle some design issues with the preliminary installer (the one that handles dependencies). It's very challenging designing a functional GUI in Netbeans, and then having to modify the code to work within the context you need to use it. For example, the code is command-line at heart, and will only pop-up dialogs when user response is needed. This leads to a hierarchy of GUI classes being spawned on top of the command-line engine, and there are some issues with sharing data between these various classes. I put a lot of work into this last night and will pick up here today since it's the area in which I'm set to make the most progress.

3. Dependent on #2, once the dependencies are verified/installed, I need to add some basic lines to the BitRock XML file to export some environment variables. This will take all of 10 minutes, just a messy loose end that can't be addressed until the depends are satisfied.

4. There is a little more development to be done on actually detecting the dependencies, but this is one of those issues that I've figured out how I can do it, I just need to complete the idea. No more problem solving really involved here.

5. A bit of work needs to be done for the Uninstaller. The reason is due to how OpenMRS functions. It's not a typical program in that the Installer doesn't create all sorts of registry keys, and there aren't a whole lot of files associated with it. Additions will need to be added to the BitRock Uninstaller (probably just some simple Java code) that handles removing of the war file, configuration of Tomcat, etc... Nothing too seriously hard.

That's about all I can think of now, but I may be forgetting some things. Hope everyone's project is going great!

Installer Progress Report

Well folks, the wheels are moving again! I've decided to use BitRock for our installer builder as opposed to izpack/nsis/any combination of the two. Check them out here: http://www.bitrock.com

I contacted BitRock and they agreed to provide OpenMRS with a license for their installer builder. It turns the 30-day trial download into a never-expiring full version. Even better, in the next few months when they have some time, they will build a "Custom Stack" for OpenMRS which will handle the dependencies automatically...FOR FREE!

Until then, I've started work on the BitRock installer and hope to have a beta version running by the end of the weekend, but let's say Tuesday to be safe. The big issue will be the Runtime Properties file. I'm having some issues with BitRock's scripting system (very easy to use though, by the way) to substitute text in files based on a given search pattern. It's all handled by basic XML, but the documentation for this particular portion isn't very clear. Aside from that, the BitRock portion is essentially finished, I just need to doctor up the logo images as well as reformat the license agreement / readme to work within the BitRock text display. Then, I'll still have to fight the dependency checking for MySQL and Tomcat.

We've more or less agreed that the website will instruct the user to load Java Runtime first, then grab our installer. We'll provide a direct link to the JRE EXE at Sun, however. This decision came about because Java code is the easiest way to check for depends on Windows machines, so we really need to have this as a pre-prerequisite.

I'll keep you updated and hope to have some screen shots for you soon, thanks!

Status Update

Hello again. Sorry for the delays. I've been brainstorming with my mentors and Paul about some of the intricacies of the Windows installer. The nice thing about Linux is that dependencies can be checked via built-in command line utilities in a very straightforward fashion. On Windows, however, that is far from the case. The abilities of DOS BATCH scripting range somewhere between 0 and Useless.

While looking at some of the scripting options out there that have been designed for installer applications, I was again not pleased. NSIS seems to be a popular one, but the scripting language is really complex (and un-necessarily so). This led me to just cook up some Java code that executed the version commands of each of the depends and then did some string manipulations in order to extract the version numbers. This is the same way the Linux version handles this issue. Also, in this process, I'm aiming to stay away from looking at the Registry because that would be a downfall of XP to Vista functionality. For example, the Java entries aren't even remotely the same between the two operating systems.

The real problem will come with MySQL and Tomcat because 1. MySQL doesn't add itself to the users path variable, so we can't directly execute the command and 2. Tomcat is really difficult to check for version info; even on Linux it's a bit hackish but effective. The issue will be trying to achieve that same goal on Windows, but by looking at the files that Tomcat uses on Windows as compared to Linux, that may not be possible.

So, that's where I am for now, sort of spinning my wheels at this point looking for the best solution. I like to think out my problems before getting too involved in actually coding something up as to not waste any effort, but nonetheless progress is being made. I'm gearing up for my visit with the OpenMRS guys next week, so that should be a very productive day and I anticipate a lot of working getting done there. I'll keep you guys posted, take care.

Status Update

Hello everyone. It has been a while since I've posted an update to this. Since my last post the focus of the installer has shifted from Linux/OSX to that of Windows. According to Paul, around 85% of the implementers will be using Windows, so that needs to be the immediate focus. So, my current focus is learning the tools of the Windows trade, and then getting a basic installer going that I can build off of. I hope to have a lot of this work knocked out by the end of the weekend.

As for the Linux/OSX installer, I should have no problems stepping away from it and then revisiting it later. The script is in a relatively stable and mature existence right now, and the main issues left to be addressed with the Linux/OSX installer involve design choices (how to distribute packages, how many different downloads to have, etc...). I've been having in-depth discussions with a lot of people trying to resolve all of these design issues, so I'm not at all worried that the final product will be great.

I'll have an update by the end of the weekend detailing some of the struggles I encountered while trying to "port" my Linux/OSX script over to Windows, the technologies I used to achieve the task, and my outlook on the future. Good luck on your projects, have a safe weekend!

Linux / OSX Dependency Checking Script

Hello all. Today, I spent the better part of 10 hours writing a BASH script that aims to identify dependency issues for OpenMRS. The script seems to work on most any Linux distro as well as OSX. But please, test it out, and let me know what you find. If something doesn't work, chances are parts of your system are out of date. Before running the script, please ensure that you have an updated version of BASH. I'm running version 3.2.17(1)-release.

$ bash --version
GNU bash, version 3.2.17(1)-release

The script depends on AWK as well, but the version shouldn't matter and most systems have this by default anyways. The script will notify you if you are missing needed dependencies, or if the versions you have are out of date. If you receive syntax errors, that's what I need to know about. Also, if you are absolutely positive that the script is providing wrong information (i.e you have the latest version of XXX app, and it says you either don't have it, or it's too old) tell me that as well.

You can download the script here: http://discosoup.net:8080/~agent/depend-check.sh
(Make sure you open that in a new tab)

Just do a chmod +x depend-check.sh and then:

bash ./depend-check.sh

and you should be set.

Thanks goes out to Matthew Harrison "[omegentoox]" for helping me test the code out on a few different platforms, as well as for the hosting of the script.