Let’s rewrite Hudson from scratch!

Because I have nothing better to do with the eight hours I spend in my company’s office building I felt it would be a great idea to sit down in from of a vi prompt and rewrite the Hudson build server all over again! From scratch! With no syntax highlighting! Without help from any of its core dev team! Ain’t I cool? Hi, I’m Cliff. You’re here because you too would like to waste hours of development time toiling over a build tool or IDE setting for years… just to make it do what it was doing three weeks ago before the system admins decided to switch all network traffic to route through a SOCKs server then through an authenticating HTTP proxy which is managed by a complicated key based 256bit encryption mechanism hosted on a Novell server that mandates each employee drive across the parking lot.. in the rain… and place their thumb on a high-tech print-scanner to acquire a key that is only valid for 2 1/2 hours after which the entire process must be repeated to continue accessing private company systems. Yeah, that’s why you’re here. That’s why I’m here too. After all, if you don’t get that one particular tool working the rest of your life will be a living nightmare of, “why am I not getting optimal results? Oh yeah, it’s because I forgot to do the manual 37 step process just before checking my changes into svn. Lets add step number 38 to prevent the disaster that just occurred last Wednesday when we tried to demo for our CEO.”

On to today’s topic. No I didn’t actually decide to rewrite Hudson. I just got tasked with figuring out why we don’t have CI in our project. That turned into the, “oh yeah it’s because this part of our project runs on a later version of Hudson.” That became, “why can’t we downgrade?” Which was answered with, “because we put so many man hours into getting to this point all of which would need repeating.” this ultimately turned into a hack that depends on Bazaar brilliance. The hack intermittently falls over so it became my job to revisit why we can no longer use normal subversion tools. When I got deep into this task I found myself staring into a vi prompt on a Linux machine looking at the Java source code which propels Hudson into action. Its bad enough that I made several failed attempts to build Hudson from source on my Mac each which consumed valuable CPU cycles and upwards of 10-20 minutes. It became really painful when I knew I had to point Linux through ssh at the several hundred megabyte (Gigabyte?) source package sitting on my Mac. Why not just checkout the source directly in Linux? Well the initial checkout took hours on my Mac and I wasn’t sure whether it was due to rainy conditions in the weather or client side bandwidth or slow server side response time and I wasn’t willing to do yet another bout of research just to get the answer to question which really isn’t critical. So here I am, looking at Java source and unable to rapidly navigate it as I could in IntelliJ Idea. Its a sea of text and I’m lost in the middle without a clue. I have Spotlight which pin-pointed the location that needs to be fixed. but I have no confidence that the build I execute is responsible for the war file that I ultimately collect because this war file is in a non-standard location. Also, the instructions for building this war file are comparable in complexity to the non-standard structure of the project. This structure is, in turn, comparable to the complexity of the source code. I’m lost, frustrated, and I just want it to work. On a good day (a Monday) I’d love to obsess over how the Hudson team has managed to tackle whatever problem that lead to the complexity that is their current build system. But on a bad day (a Friday) I only care that the end result of their build system can find the source code that is locked behind yet another ocean of complicated security constraints. I just want things to work. I don’t want to learn their interiors. I want them to do the thing I they were designed to to.