1. Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says 'we care about your platform' like shell script launchers.
2. While you're writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh.
3. Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file.
4. Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma.
5. If you do want customization, then force users to define env vars. Since every user's environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they'll feel it's like a personal customized version that is tailored for their own needs and nobody else's.
6. Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, than unless they explicitly ask for something else, they want help.
7. Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional.
8. Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where.
9. Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it's there for a reason you know.
10. Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it's better to be safe than sorry.
11. build.xml should be your gateway to everything. Don't be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They're from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run.
12. Consolidation is for the weak. A single buildfile basically screams out 'I'm a girl and like bunnies and wear pink fluffy dresses'. If you're going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they'll get funny ideas that they could have done it themselves.
Home 
