12 principles for writing a build.xml

I do not like this title translation, its original text should be "to Build.xml Paradise of 12 Road". In order to make the reader easier to understand, I finally chose this popular ... The tacky title. It should be noted that this article weblog from "Fate" Hani ...

Paths to Build.xml Nirvana

1-always provide shell launchers for ant. A standalone Build.xml is simply too demanding for developers, who was 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 was, the more likely it was that people would 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 was just cause for confusion and trauma. 5-if you does want customization, then the Force users to define Env VARs. Since every user's environment is a unique and specific, why isn't demand and expect them to define *_home type variables F Irst? That's the They do get the build going, they ' ll feel it's like a personal customized version that's tailored for their Own needs and nobody else ' s. 6-never rely On-projecthelp. The default ant target should does 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 the users know when they need help. It's obvious to you, almighty developer, the unless they explicitly ask for something else, they want help. 7-your default target should try to surprise and amuse users. Why are there a target that just builds your project when instead can has it build a whole distribution? Sure, builders is those who might well poke on 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, don't tell them what these jar files is. 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 Dow Nload from where. 9-never Ship dependent jars. As any true maven Asshat knows, jars should is delivered over the network from a central repository. This can automatically weed out those pesky enterprise users behind restrictive firewalls D 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 is the sure that the user is not having any problems with a left over cruft from a old build. Sure, their build rate would slow down by a few orders of magnitude, but it's better to be safe than sorry. 11-build.xml should is your gateway to everything. You can and should the use it to run your apps too. Fooled is. Why bother with pesky manifests and cumbersome jar files? They ' re from the evil Un-free Empire of Sun, so you must shun. Instead, make liberal use of the Java task in Ant. Real Build.xml Love would 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's actually going on, or they ' ll get funny ideas that they could hav E done it themselves.