Recently I had to spend a fair amount of time working on CONGO on a Windows XP platform. Stonekeep is doing doing it’s first event where CONGO will be running entirely on Windows XP, so all the environmental stuff I’m used to having under Linux doesn’t work, naturally. Things needed to be updated. This presented many challenges…
Normally I’d just import CONGO into Eclipse (where I’ve been doing most of my Windows development), and run with it, but CONGO was my first ‘big’ Java app, and, well, I made some poor design decisions that make moving it into a formal structured environment like Eclipse… somewhat problematic.
What I needed to do was set up my Windows XP environment to behave very in a similar fashion to my Linux environment, without trying to reproduce Linux-under-windows. I’ve gone the Cygwin route before (which tries to emulate a Unix environment completely), but I found the inconsistencies got in the way of being productive, and the installation overhead is enormous. So I needed a compromise.
There were several basic functions I needed to have in order to run the two sides of my application successfully. CONGO consists of a standalone ‘application server’ (called ‘cserver’) which runs in it’s own standalone Java process, answering XMLRPC requests, and a PHP-based webclient called “Coconut”, providing the user interface. To run both these pieces I needed Java, PHP, a webserver, a database, an installation tool, an editor, and a way to interact with my SVN repository.
A large part of my needs were covered with XAMPP, a bundled set of tools that provides LAMP functionality to a windows environment (WAMP?). With one swell foop, I had a PHP interpreter, an Apache webserver, and a MySQL instance, plus a database tool (phpMyAdmin).
Sun provided the appropriate JDK (Java Development Kit) to compile the application server as needed. I don’t have a binary distribution of the code yet, so an installation consists of checking it out of SVN and compiling it. The JDK installed just fine (into C:\Program Files\Java\jdk-versionumble)
For an editor, I chose to work with JEdit for a while. It’s a pretty editor, and is completely Swing based. It has some annoying twitches, and I’m not sure if I’ll continue using it in the long term, but for this event-cycle, it was fast, workable, and did the job just fine.
The Build Tool
Build tool – This is one of the sticking points for portability into Eclipse. I don’t actually compile CONGO in a ‘normal’ fashion, and my class definitions are all screwed up. To address my odd setups, I use Ant, a very very good build tool specifically designed to work with Java projects. I had already been using Ant build scripts on my Linux installations, so having this available under Windows was a huge win.
I downloaded the Apache Ant binary distribution, and unpacked it. Because Ant is basically just a simple command line tool, it really doesn’t have a Windows installation process, it just needs to be unzipped. I put it in C:\Program Files\ant.
The SVN Client
This one was a toss up. All my code is stored in an SVN repository on a remote machine in a colo facility. In order to check in and out code, I needed to have an SVN client on the machine.
The natural inclination would be to download the command line SVN client, which is available from Tigris.org, but that seemed to be me falling into the “it must be just like Linux!” mode, which I was trying to avoid. Instead, I opted to install Tortoise SVN, a tool that integrates SVN functionality right into the Windows explorer. This turned out to be an EXCELLENT choice. I found TortoiseSVN to be stable, fast, and eminently useable for my checkins and updates, without having a steep learning curve.
So far so good. I had all the tools I needed, but Windows isn’t normally comfortable with command line only interaction. I could spend time configuring tools into JEdit like Ant Farm and the like, but that runs the risk of being distracted with some serious yak shaving, something I didn’t have the time or the inclination for. Instead, I opted to set up Windows to handle command line use of Ant.
The primary challenge here was setting up the paths correctly. Under Linux, I’d simply add the path to my .profile and off I’d run. Under windows it’s slightly more challenging. I found a handy little shortcut for doing a ‘fast’ path change similar to using $PATH in Linux:
In Linux:$ cd /usr/ant $ export PATH=$PATH:`pwd`
In Windows:C:\> cd "\Program Files\ant\apache-ant-1.7\bin" C:\Program Files\ant\apache-ant-1.7\bin> path=%path%;%cd%
This shortcut is a great way to make sure all the things work correctly before actually modifying the system. I did this for both the JDK and for Ant, and lo! I was able to do ‘ant’ commands, builds, and run my app. Hooray!
The last bit was to change my default system path under Windows to include these new directories. This was accomplished by following the tortuous path:
Right click on My Computer->Properties->Advanced->Environment Variables…
Then scrolling through the ‘System Variables’ until you find ‘Path’, click ‘Edit’, and append on the JDK and Ant binary home directories. Windows thoughtfully makes this input window only about 30 characters wide, without the option to resize, so expect to do a little scrolling. Phew. But this meant these paths were set every time I started up a CMD.exe shell
At the end of it all, I had a clean environment where I could not only run my appserver, but also use Firefox to access Coconut. Hooray!
It’s hard to buck trends. There’s no question that Windows is used for serious work, but many Linux users scoff at the concept of using Windows as a viable development environment unless you’re doing Windows specific coding, such as .NET or Visual Studio type work. Much of this derision comes from the different approaches to environment. Windows tends to be pointy-clicky, doing a lot of ‘assistance’ to the developer. Linux programmers prefer command line editing and compilation (though that is rapidly changing as tools like Eclipse, IDEA, and Netbeans gain popularity). Regardless, this article shows it is possible to set up Windows for simple command line operation, with some of the benefits of a full GUI, without spending hours upon hours tweaking and installing random tools.