Slashdot Mirror
Ant - The Definitive Guide
As a long time Ant user, I have written many Ant build scripts, automating my builds and speeding up the overall development cycle, mostly relying on its excellent online documentation. As a Java developer, I have admired its simple and intuitive interface and the modular design. So on getting Ant: The Definitive Guide in my hands I wasn't expecting a whole lot new to learn, and thought of using it only as a reference book.
After having the book on my desk for more than a month, though, and occasionally flipping through its pages whenever I would otherwise have consulted the online documentation, I must say that I had been missing out on some very important things: tasks like ftp and war deployment that I was simply not aware of and had never felt the need to look up, but could very well use. The other interesting thing I noticed was that my build scripts became smaller, more modular and easier to read.
Like most books in the The Definitive Guide series, Ant The Definitive Guide assumes a certain level of familiarity with underlying technologies such as Java and XML and focuses on providing complete, reference like details of Ant features and tasks. These description are generously supplemented with examples and code fragments.
But so is the the online documentation for Ant! Will someone gain additional insight in using Ant, or be able to work faster, or make better use of Ant capabilities, by consulting this book, instead of the online documentation for a particular Ant task? To find the answer, I randomly picked two topics -- filesets, an important and oft-used Ant datatype, and javac, a core Ant task -- and compared their online description with the one in the book. Here is what I found.
Besides the datatype definition, explanation of various attributes, sub-elements, and the examples, the book also covers how to specify conditional inclusion or exclusion of certain filename patterns when a property is set (or unset). Though this can be inferred from online documentation by a determined user, this particular use is far from obvious. The coverage in the book also talks about the relationship of the fileset datatype with the javac task, pointing out that the fileset attribute dir is equivalent of javac attribute srcdir, as attribute dir will be confusing in javac: is it referring to source directory or destination directory. This is the kind of insight that really helps a user.
The treatment of the javac task in the book is not much different from the one in the online documentation. Both have almost the same material, though the information in the book is better organized for new users. On the other hand, I found the online documentation to be more complete, especially with respect to the compiler specific options and behavior idiosyncrasies.
Here is a rundown on what the book covers: Chapter 1, Getting Started is a quick primer on Ant, with sufficient details for a new user to start using Ant for very simple build tasks. Chapter 2, Using Properties and Types introduces the building block tasks and datatypes, such as property, condition, fileset, path like structures, selectors and so on, used in other Ant tasks. Chapter 3, Building Java Code covers the tasks and activities around compiling Java source files (ie; javac), organizing the build steps in various targets within a single build scripts and/or across multiple scripts, generating documentation using javadoc and creating distribution jars and zip files. The rest of the chapters are devoted to tasks for specific purposes, such as launching external programs (Chapter 7, Executing External Programs), copying files and manipulating directories either on the same machine or over the network (Chapter 4, Deploying Builds), running JUnit tests (Chapter 5, Testing Builds with JUnit) and so on. There are also separate chapters covering interaction of Ant with XML and XDoclet (Chapter 9, XML and XDoclet) and with Eclipse (Chapter 11, Integrating Ant with Eclipse). The last chapter, Chapter 12, Extending Ant, talks about extending Ant by doing things like adding your own tasks, creating custom filters, writing your own build listeners and loggers etc. This chapter also has a small section on how to embed a script written in one of the supported scripting languages within an Ant script.
As you can see from this outline, the book covers almost everything that is to know about Ant and other related software.
So, what is not so good about this book? Well, I didn't find anything wrong with the topics which are actually covered by the book. Of course, there are additional things that I would have liked to see in the book: (a) A good sample Ant script which could be used as the starting point for most small to medium-sized projects; (b) A more thorough explanation of how dependencies among targets determine the execution sequence and how this fits in with explicit invocation of targets; and (c) pictures to illustrate some of the concepts such as life cycle of an Ant task, selection of files in a fileset and the dependency tree of targets.
Overall, I found the book to be comprehensive, well organized, easy to read and good value for money.
You can purchase Ant: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I like how the make file are XML based. With other makefiles, you get stuck if your tab has a space in it :/
Good review though!
So, what could a book say that is already not available online?"
Nothing, you have to read it.
Sorry, i just had to...
for free wallpapers, visit Sargosis.com
So, what is not so good about this book?...Of course, there are additional things that I would have liked to see in the book: (c) pictures to illustrate some of the concepts such as life cycle of an Ant
Here ya go:
Life Cycle
I have a web service application that resides as a seperate module in CVS. I needed the ability to build a JAR, and move it either to local qa application servers, or a remote server.
I thought I'd try Maven. After spending 4 hours looking for and reading what passes for documentation on the Apache site, I gave up, and wrote a batch script to do it in 15 minutes.
The Apache docs suck for many of their projects (Tomcat, Maven, Axis). Do the developers do it on purpose so that they can make money writing books explaining the tools? I have no idea.
To be fair, some Apache documentation is good (in the commons projects, like CLI and HttpClient).
This book is cheaper at bookpool.com ($22.50) than at bn.com ($27.96 bn price/$25.16 member price). Get it there and save a few $$.
GOBACK.
I have worked on a couple products which have used ant as the build system. These were released a few years ago and I think the version was ant 1.3. The online doc at the time ~2002 was mediocre. I think it has gotten better now, but the book still covers all the basic features you will ever need and decreased our old make full build time from 30-40 minutes to about 10 with ant on the same hardware, as well as making it much easier to make changes and add new steps. When making minor changes ant will recompile and determine dependencies in just a few seconds where our make system would still take 5-10 minutes just for incremental change. Granted our make system could have been optimized, ant was a good excuse to start over. I have a paper copy, but do also use safari to search through the text. This gives you the best of being online and having the book.
Is there anything out there that is (a) easily deployable (nothing turns off a prospective user than being told to download and install a complicated build system that depends on $LANGUAGE_OF_THE_MOMENT), (b) suitably flexible that I can customise it to work with all my little build tools, and (c) sufficiently elegant that I won't want to vomit looking at my build scripts six months later?
So far, the only thing I've found that works at all is traditional make. Which, I'm afraid, sucks. Makefiles scale very badly (recursive make. Eeeaah), don't handle disparate rulesets well (I want to build these C files with this rule and these with this other rule... oh, wait, I can't), and the dependency handling is practically nonexistent (you can fake to a certain extent with .d files, but that all falls apart as soon as you need to depend on dynamically made files).
A case in point: I maintain the ACK, a portable compiler toolchain that's about 20 years old. The build system is an intricate network is shell scripts and recursive makefiles. It works, but it's largely incomprehensible, very slow, doesn't handle incremental rebuilds, and is going to be a maintenance nightmare should we ever need to do any major revamps. I'd love to replace it; I've gone out actively looking for something better --- and I've failed.
Any suggestions?
This has been a public service rant by a stressed build technician.
I know the moderators will hit me for this, but from the sys admins point of view - ant is evil!
/etc !!!
/etc is a very good example of what is wrong with plain text files - no single program or API could ever handle the range of formats of files there! Incidentally - XML IS plain text.
Ant isn't for sys admins.
It is simply another build program to learn. The C and C++ stuff for the kernel is "make" - now I have to learn "ant" for Java programs.
As Java isn't used (yet!) for kernel stuff, what is the problem?
I am not against learning new things, but where some people see XML as a good thing - I think it sucks! I despise any time I see a config file that is XML. XML is for the "parsing impaired" - use a plain text file like everything in
Sorry, wrong way around. XML was designed specifically from the start to be parser-friendly. There are very simple APIs which handle any XML file such as SAX.
If folk want something better than make, but don't want something so Java-centric. Have a look at SCons.
:) (Yes, SCons handles Java as well as C or C++).
The software, as well as the confuguration files, are actually Python. But, you won't notice until your build requirements get quite complex.
Scons keeps track of dependencies using MD5sums on the tail nodes. This takes up a bit more processing time, but more than makes up for it with highly-parallelizable builds (SCons + distcc totally rocks), guaranteed correct builds (never do 'make clean' again!).
We've just converted a project from Make to SCons, and it's cut our build time by about 40%. I might even be able to convince our java guys to try it out, too
Oh... And I can use make and a Makefile to compile C code and the Java code of the same project.
If you understood Ant, you would know that it can do this as well.
A graphical aproach I've seen to handle ant scripts is done by NetBeans. Starting with version 4 all the project management is ant-based and you can add targets and parameters from the IDE.
Last time I used it the paths were added as absolute paths so I continued editing my scripts by hand, though.
If there isn't a GUI for editing ant files, there really should be.
Badass Resumes
The best thing about using make and a Makefile instead of Ant is that I don't need to read books like this.
You don't need to learn make from books because you already know it, and if you knew ant, you wouldn't need to read books like this either.
Even if you didn't know ant, the online documentation is sufficient. That is how I learned ant.
-=Lothsahn=-
Hey, make fiends, try this: add new functionality to make, extending its syntax. PITA, you say. It's very simple with ant.
This book is also available online at O'Reilly's Safari site.
Also, although Ant is used mainly to build Java, it is NOT java-centric. It can be used to compile any language.
Can someone explain to me the difference between Ant and Maven? I have noticed almost everyone supports Ant, but there are people who also do Maven. Are there any advantages, disadvantages, are the different but overlap greatly, and why does Apache support what appears to me to be two competitive technologies...
Very confusing to someone who just has a high-level understanding of Apache world.
D.O.U.O.S.V.A.V.V.M.
Maven has serious issues as eloquently explained by Hani. Be sure to check out his newest article on mergere, the company that attempts to support maven.
There is a port of Ant to .NET available from here.
It had a great following until MS announced MSBuild.
Unfortunetly, MS put RIP on it when they created MSBuild, which comes with .NET. Visual Studio project files are MSBuild files.
1. The pulling teeth part! You need to use the 3rd party ant-contrib package to even get basic if-else and for loop functionality. And even then, since it's XML, you end up with crap like this:
.class file or somesuch. What ant needs is something like what gcc -M does for make.
<if>
<equals arg1="${foo}" arg2="bar"/>
<then>
<property name="bat" value="barf"/>
</then>
</if>
... give me a break.
What I'm always hoping for is a build system that is just a perl / python library, so I can write the build script in a real language and call the build system when I want to.
2. Ant's simplistic rebuild-on-file-mod way of doing things misses things. Say class A.java calls class B.java. You build and all is well. Then you change B.java's interface, but not where it is called in A.java. By right your build should break now, but ant only rebuilds B.java, because it's file mod time is updated; it does no analysis of what depends on it and should be rebuilt. So you run the program and if that line of code gets called you get a NoSuchMethodError, examine that stack trace, and manually delete the
... hey, I use it, but it's the year 2005 for crying out loud.
I know Make. Make is a friend of mine. Ant is no Make.
.bat or shell script...but that's sadly about where it ends.
.bat/shellscript replacement...and that's it. Claiming it is a legit replacement for Make is to completely misunderstand what Make actually is and does. That doesn't mean Ant isn't useful, it is, but it is no Make.
Ant can automate Java builds slightly better then a
The major problem is that Ant has no built in dependancy system. Dependant tasks don't count as they have no targets and thus nothing to check for dependancies. All real dependancy checking in Ant is embedded in the Ant task code...which varies task to task and worse yet has little to no documentation (not even documented to be taking place or not!). Examples are javac, zip, copy tasks.
Ant + Javamake gets closer to a Make replacement, but not completely.
But really, to be accurate Ant is a portable
My
It has been a source of constant dismay to me that something has not arisen to replace Ant in for Java builds. The Ant project has created a terrific mess where people essentially *program in XML*. XML is a set of data structure markup semantics, not a programming language. No potential of repurposing ant build files exists, another knock against using XML. Therefore, from a software architecture perspective, Ant is one of the biggest misapplications of technology I have seen to date and despite that, staggeringly popular. I rest my case and shake my head.
Make is for C programmers,
Ant is for Java programmers,
Maven is for idiots.
Some how I think most /. would better associate with the later meaning of the word.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Good stuff...
[Doesnt eclipse use Ant for its builds? ]
No, it doesn't (Thank God!). You're thinking of netbeans.
Why 'thank God'? Why should internal use of Ant be a problem? On the contrary, it has major advantages: It means you can build the project outside of the IDE, and it means that the IDE can make use of just about any Java tool, as almost all of them provide functionality as Ant tasks. Compare this to eclipse, where you need to install plug-ins.