Spring Cleaning

Hello faithful Cosmic Game Engine followers!

The team recently completed a two-week refactoring party on the avatar system. A lot of the early code needed to be looked at again through the lens of over a year of experience as well as the feedback from early API users. Attention was paid to locking down the API (that is, only exposing the essential pieces), refactoring the classes to fit a more "package as module" design rather than "package as a way to organize source code", throwing exceptions as soon as things go wrong, and removing unused cruftiness.

One part of this effort that we decided to test out was the usage of automation wherever possible in the development process. The stated goals of this effort were:

• Host a local Subversion repository (to speed commit / update cycles)
• Use static analysis tools (more on this later)
• Host a Bugzilla install to track pending issues
• Use a continuous integration server to detect problems as early as possible

The first step here was to determine an operating system to use. My initial choice was OpenSolaris, but unfortunately the RAID controller on our server was not supported under OpenSolaris (or several other OSes as we discovered). After a myriad of different OS trials (including FreeBSD, SuSe, and Debian), we had the most success with Ubuntu Server. From this point I set up Apache webserver and Tomcat. Installing bugzilla and subversion turned out to be pretty simple, but getting tomcat to work well with https proved a little more tricky. Once the subversion server was up, we determined that having an html browsing interface for the repositories would be great. There are plenty of commercial products for this, but I decided on ViewVC. ViewVC even has a plugin for Hudson, although I could not get it to work without modifying my install (shame on the plugin writer! Give me a config option to change!). My goal was to have a single htpasswd file that was shared between as many services as possible. This was possible for every tool except bugzilla which has been a bit of a pain to configure. The rationale behind this goal was to pass off administration of this system to anyone. Rather than needing to be a competent *nix administrator, a person wanting to add a new account to the build server / svn / https documents simply needs to run a handful of commands from the shell.

For our continuous integration server, we went with Hudson. Hudson has proven to be an extremely useful tool. Firstly, we were able to set up automated builds that are triggered by subversion commits. Secondly, we were able to easily tie our static analysis tool in with Hudson (through a plugin) and have it run periodically on the code base. Hudson is easily deployed via Tomcat, although again some voodoo is required to make tomcat play well with apache https access. I am particularly pleased with how much configuration and administration is possible in hudson entirely through the web interface. Plugins can be installed and the software can even be updated, all by clicking through a few pages in your browser.

The static analysis tool we settled on was FindBugs. This tool is awesome! FindBugs is a java tool made and maintained by the University of Maryland. It is free software (LGPL) and it can detect all sorts of potential problems that may have otherwise eluded developers. Not only does FindBugs analyze your code, but it can also analyze dependency libraries that you provide. All of the bugs that it finds can in turn be linked back to the source code to immediately point out the problem. We found several problems that made us wonder how the affected areas EVER worked! In addition to finding potential bugs, it also helps to enforce java best practices through its style and convention warnings. Initially, FindBugs found 269 problems. Through the course of the code scrubbing we were able to reduce the number of warnings significantly. It was fun to proudly claim responsibility for a drastic drop in the graph overnight.

So how does all of this affect you? We will be integrating our changes into the svn repository at the Java.net Avatars Project. The current HEAD revision is 1119 on the trunk. Anything beyond this will be the result of merging our changes branch with the trunk. This includes pretty prominent API changes, so if you have code already relying on the existing avatar system, it may need to be changed to cope with revisions after 1119. Following this we will be working to roll these changes into the Project Wonderland 0.5 codebase. Stay tuned for more!