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 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, 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 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.
October 31st, 2003 at 10:29 am
Seventh post!
October 31st, 2003 at 10:52 am
x15 comentário!
October 31st, 2003 at 10:53 am
>> Never ship dependent jars
Or better yet, ship them every jar on your system – why not a snapshot of your development environment and make them download 190+Meg.
Personally I prefer http get… – and whats more, I am manly enough to work out how to use these crazy new fangled inventions called “Proxies” from behind corporate firewalls. Some “Proxies” even handle NTLM authentication.
-Pippy Long Stocking
October 31st, 2003 at 11:25 am
Could you repost this article by inverting all the 12 paths pls.
Thanks,
Happy
October 31st, 2003 at 1:03 pm
I have seen all of these, even perpetrating a few of them before I knew what I was doing. That said, the really amazing thing about this list is that there are so few ways to make bad Ant build files. To a surprising extent, Ant Just Works, solving build problems with efficiency and grace.
One more –
13 – In your “java” and “exec” tasks, liberally use “arg line = ‘…’” rather than “arg value = ‘…’” or “arg file = ‘…’”.
Do this especially for arguments that are file names or paths. This allows you to reintroduce the subtle OS, shell, and file naming dependencies that were so beloved from pre-Ant build systems.
October 31st, 2003 at 1:13 pm
I have seen all of these, even perpetrating a few of them before I knew what I was doing. That said, the really amazing thing about this list is that there are so few ways to make bad Ant build files. To a surprising extent, Ant Just Works, solving build problems with efficiency and grace.
One more –
13 – In your “java” and “exec” tasks, liberally use “arg line = ‘…’” rather than “arg value = ‘…’” or “arg file = ‘…’”.
Do this especially for arguments that are file names or paths. This allows you to reintroduce the subtle OS, shell, and file naming dependencies that were so beloved from pre-Ant build systems.
October 31st, 2003 at 1:28 pm
Dear Mr. Proxy dumbass: You can’t always tunnel everything through a proxy. A proper distribution should list the dependancies and versions, and provide you with a “here’s everything” archive as well as a “here’s nothing” archive leaving it up to you to get them yourself (in case you already have them.
And to the rest of you: Ant sucks ass. It is the worst scripting language ever written (no fucking if statement or proper loop???) You just like it because it’s XML. make is far superior. Jesus java `find . -name \*.java -print` is better.
October 31st, 2003 at 2:03 pm
Dear Mr David Dumbass,
>> You can’t always tunnel everything through a proxy
Thats an astute observation!
But http does remarkably well…
October 31st, 2003 at 3:02 pm
ANT needs to define the tasks as interfaces and simply deliver the script as a Java class/source doing stuff against the interfaces. Why do people have to express things in XML when expressing them in Java is clearly better?
XML is retarded if used for anything else than documents or configs.
October 31st, 2003 at 4:23 pm
As an ant newbie, I didn’t know that this post was sarcastic until about half-way through. It would be awesome if you could post a quick best practices for people like me….
October 31st, 2003 at 5:30 pm
klklk
October 31st, 2003 at 6:52 pm
Dude I am working with an inherited system that follows every single point. Cool eh?
Nice post.
Oh yeah, and, ant sucks.
November 1st, 2003 at 1:40 am
Who thinks ANT is a scripting language?
Its a build system DUH!
Theres some crap in the list, probably 50-50, so not too bad an effort …
November 1st, 2003 at 8:22 am
I don’t see Ant as, specifically, a build system. It is adept at building, but I do think it is very useful for just running applications as well. Not your everyday applications, but (for example), getting WebLogic up and running.
Perhaps this is just a bile against WebLogic and the massive complexity of their startup command line … but you can end up with a horrendously complicated, unmaintainable startup script … or you can use Ant to build a complex startup classpath and command line.
Some people complain about Ant syntax (or XML syntax) … but it sure beats shell script and Windows batch files!
I’d say most of the abuses you posted are the result of the wrong people being assigned to build the Ant build scripts; the folks who approach engineering as a kind of magical incantation … cutting, pasting and tweaking until it works. Like anything else, it’s better to have deeper understanding of the issues (such as the fact that projects get more complex over time and the build files need to keep up, or that different users may want to build in different directories on different O/Ses).
November 1st, 2003 at 11:49 am
I am using ant to write my poetry in a word plugin.
November 1st, 2003 at 12:16 pm
For those that want best practices the ant resource page (http://ant.apache.org/resources.html) is a good place to start.
In particular the “Ant in Anger” paper should be required reading for everyone writing an ant ant file.
November 2nd, 2003 at 5:02 pm
I use run tasks for two reasons.
1 – Frequently I’m helping C++ coders move to Java. I prototype some stuff for them and ship it off. Who knows what OS they’re going to us. I just want them to see my code and run it (helps squash the enevitable C++ diehard from having another complaint).
2 – On those rare occaisions I touch a Windows box I use Cygwin. I can’t for the life of me get classpaths right. Ant does.
November 4th, 2003 at 6:55 am
Hey, it’s very ease to abuse things in general (and software in particular). The point is that ant works and does its job. If it doesn’t work as you might want it to, you have the source code and you’re free to change it.
Especially with open source software, one should “Use it, not abuse it” and should not expect it to do out-of-the-box things that commercial applications don’t even do.
November 25th, 2003 at 1:16 am
I’d like to add sth. to point number 6 talking about -projecthelp: even if this option could be helpfully, you find it was once at the beginning written and nobody took care of mantaining its information … so never trust a projecthelp information!
December 16th, 2003 at 4:18 pm
Hmm… while launching from build.xml _is_ bad, I use it to generate shell scripts for the actual launching at the moment. That comes in rather handy, particularly because changing a dependent JAR file at some time during development results in the launcher scripts being rewritten. Of course you can do this with a ‘for’ statement in bash, but on Windows it’s not quite the same ease. :-)
September 16th, 2005 at 9:29 am
For those complaining about no IF or LOOP statements in Ant, checkout the ant-contrib projects at http://sourceforge.net/projects/ant-contrib. Download the .jar file for the latest recommended release, drop it in your ant/lib folder, add one line to the top of your build scripts, and you can IF and LOOP ’till your heart’s content. There are also alot of other nice features in the ant-contrib project that you can use to enhance your Ant builds.
January 13th, 2006 at 9:08 am
Oh, by the way. In case you were wondering. Ant sucks. Makefiles not portable? Gee, I guess 10,000 sourceforge, GNU, and Perl projects are all wrong. Gee, isn’t it funny how all those things compile on every platform known to mankind? Without requiring Sun’s f’ing gazillion megabyte downloads. So you can write bogus xml scripts that make doing something simple like `ls *.java | sed -e ‘s/blah/blahblah/gi’ | my_cool_jcpp –enable-include –enable-defines –enable-java-as-a-real-language-instead-of-an-irritation` almost impossible to do.
Ah, yes, Ant. What a great tool–not.