I was talking in the halls of SITE after my last exam about AudioMan with Aleks and Karen and among other things we talked about distribution and Java. Just thought I'd write a post to get those ideas down and bounce 'em off readers.

AudioMan will primarily be a Windows application but SWT is cross-platform so it could, in theory, be easily "ported" to Linux and Mac OS X with a little work. This will probably be one of my little pet projects that no one else will care about but it would be nice to release the same code on three platforms at once. The only difference is that the Mac OS X and Linux integration will be crufty unless people start caring about it.

Second up is an installer. While Java programs don't need an "official" installer I think it's just nice from a usability standpoint. Previously with AudioMan we used a ZIP file and README. Most users will download a ZIP file and not have a clue what to do with it or even know that they are supposed to read the README file. Besides making the installation less painful, installers are also a nice place to do all of the platform specific stuff to set up usability things like shortcuts and menu items, overall just make the app seem more integrated. People shouldn't have to know that it's a Java/SWT application. We'd like to fool them. ;)

The build process is tied to this because it produces the installer files that people can download. There are two build processes actually: one for developers as they work on the code and the other to produce releases. These should be kept as similar as possible without hamstringing the developers too much. We don't want an error in a release build because of a build process difference but we don't want to slow down developers when they are just hacking code.

Ant is an easy tool to use once you get the hang of it -- we used it to produce the AudioMan builds before. But I would like to further automate that build process to do the following:

- compile the code
- run the JUnit test suite on it, with jcoverage instrumentation
- make the JUnit and jcoverage reports
- configure/make the installer based on the compiled code
- upload the installer and reports to the web site

Then you can fire off a new build with a click of a button and everything is done for you. Zero maintenance. As well, you can configure Ant to let you make a new build only if the source code has changed in the last day. Then we don't get daily builds for a month that are all the same if the code hasn't changed. Ant will be the place where platform specific builds for Linux and Mac OS X are configured as well.

The Ant integration with Eclipse is getting nicer in 3.0 but developers will still probably prefer to use Eclipse's built-in compile and JUnit plugin rather than use the Ant window. That's definitely OK but a sanity check with the Ant script should be done at the end before committing to make sure that you don't break the next build. In other words, the Ant script will be the word of law on this project. Compiling/running and JUnit test runs in Eclipse are just for convenience. Speaking of convenience: when is someone going to make a jcoverage Eclipse plugin?

So that's my brain dump on distribution ... thoughts?

BTW, this is post #400. That seems like a lot eh? Thanks for reading.