I don't like this Title translation. Its original text should be "12 roads to Build.xml paradise". In order to make readers easier to understand, I finally chose this popularity ... Title of Title. It should be noted that this Weblog comes from "Fate" Hani ...
12 paths to build.xml nirvana 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 direct.xml file in your top level direct.xml file in it is, the more used it is that people stopwill actuly ook at your stuff in a hopless effect 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 expert the to define 12 * _h OME WAY WHEN THEY DO GEEL 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, that 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 quick builds via want 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 '
