The first step is make your build so complex, brittle, and hard to use that nobody else can even build with it, much less maintain it. Here are some well-worn techniques:

Use Ant Like An Imperative Programming Language

Make heavy use of the if and unless attributes, and try to create lots of conditional properties. Chain them together if you can. Try to get it so that it’s impossible to get anything to work without setting at least a dozen different properties from the command line. When you find yourself needing a loop structure, you know you’re on the right track.

Create Useless Default Targets

Useful default targets make it too easy. Make sure you do something that will fail after a clean checkout. And don’t use the standard build.xml filename…otherwise people will be able to build simply by calling ant. Name your build file cibld.v2 or something obscure like that.

Make One Big Target That Does Everything

Just as decoupling and encapsulating your code makes it simpler, decoupling and encapsulating actions in your ant script makes it much easier to read and use…avoid this at all costs. Put everything into one big target that cleans, builds, makes JavaDoc, deploys, runs FindBugs, emails you that it’s done, prints the results to the office printer, and reboots the build machine just for luck.

Don’t Use Metatargets; Use the depends Keyword Instead

A corollary to the OneBigTarget rule is the avoidance of metatargets. By making lots of small targets that do one thing well, you introduce the possibility of chaining them together to do different operations. These “metatargets” allow people to use the build in ways you never anticipated. What horror! Things must be done the way you define them back when you originally wrote the script. Why would anyone have the arrogance to do it another way?

If you have to decouple into small targets, make sure you chain them all together using the depends keyword. It’s almost as good as the OneBigTarget.

Avoid Self-Documentation

When creating a target, don’t give it a useful or informative name. Be sure not to use the description annotation for your targets. This can be used with the -projecthelp option in ant to print out a list of public targets and their uses! How will ever confuse people like that?

Never Refactor Your Scripts

Finally, if you do have to change something (although I can’t imagine why that would ever be necessary), make sure you leave all your old stuff in there. Granted…the source control system is probably tracking all of your changes, but you can never be too sure. It’s best to just leave all those old, crusty targets in there. It’ll confuse everyone else, and it makes it easier for your to find your old stuff without learning how to use subversion.

Once all of this complexity is in place, you’re ready for the big payoff. It was a lot of work up front, but it’s worth it, because now you can argue to your boss that build management is way too hard for you do to all by yourself. Point out that you’ve been spending 30 hours a week on the build and you should have no problem talking him into hiring a build guy to do it for you. Voila! No more build system headaches for you. Just don’t be surprised if, during the next round of layoffs, the build guy keeps his job (how could we manage without him?!?) while yours is shipped off to India.

Of course, if you DO want to maintain your own build system, you can start with a lot worse than my Nifty Thrifty Build Script