WOProject: Why You Should Care

If you get time, perhaps you could do an Ant in 5 minutes article on your website.... "Why you need Ant" I have worked with WebObjects and java for a year now, and I have never used Ant, and still I am unclear as to why I need to know anything about Ant since XCode compiles and builds my projects fine! I just don't get all this talk about Ant, and why ant integration in XCode is important and how it applies to a lone developer working on a Powerbook!

Do you know why many technologies -- especially "superior" technologies -- aren't picked by the masses? I believe a big factor is that the technology's proponents are so in love with their perfect, beautiful jewel that they don't stand back and see it through the eyes of the outsider. The outsider isn't in love (yet), and they have a simple question: "I already get all of my work done today, why should I care?"

This question is often left unanswered.

I admit I'm guilty of the crime in regards to ant+woproject. Allow me to enumerate reasons why a lone developer on a PowerBook should care about ant+woproject, in order of importance:

• Cross-project dependancies. Have multiple apps depend on multiple frameworks depending on yet more frameworks. Ant will make sure the Right Thing happens. I'll admit the technique to pull off this dependancy is hackish and overly manual, but it works. This was the primary driver for me towards ant -- previously I had hand-rolled perl scripts that would fire off pbxbuild calls in the right order. This technique is monolithic and unscalable.

• Automated deployment. ant upload builds, tarballs and scp's my App.woa.tgz to the project's deployment server. It used to take me about 45 to 60 minutes to deploy a new version of an app. Now I'm inside 15 minutes. It's still not automated as far as I would like (largely because wotaskd lacks a public API to manage instances, and I haven't bothered to reverse engineer them yet), but it's much better.

  When deployment is cheap, the rules change. Staging may become optional. As an example, I had a client in Washington state on instant messaging (I'm in Illinois). We were both looking at the live site, making changes and redeploying. 90 minutes later we were done, which encompassed 13 redeployments. And not a single user lost their state (grin).

• Speed. Even though the ant inter-project dependancy stuff is brute-force and inherently dumb/slow, I still found it much faster than PBX (I don't have any experiential Xcode/Java data to make a statement on Xcode).

• Open source. Roll your own tasks to make woproject better suit your needs. Optionally share them back with the community.

• Transparent project description. How to build a project, and everything it depends on, is enclosed in that small human-readable build.xml file. Compare and contrast with Xcode.

• Cross-platform. Personally, I deploy by uploading binary tarballs (I've been doing "xcopy deployment" for years before Microsoft invented it). However, Pierre Bernard has a different, interesting technique. He checks out a tag on the deployment server and builds the app on the deployment server. Using ant+woproject, this technique works even if your box isn't a Mac OS X box.

So I appreciate ant+woproject, which is saying a lot from a guy who generally dislikes command line environments. That said, I switched back in the PBX dark days, and Xcode has made a number of improvements since. I'll probably give Xcode another chance when a new version ships.

Saturday, July 10, 2004
12:00 AM