Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Ant - The Definitive Guide 205

Posted by timothy from the ants-are-tiny-bugs dept.
pankaj_kumar writes "Apache Ant, the Java replacement for make , belongs to the rare breed of category killer software for automating Java software development tasks. It is an Apache open source project, has won numerous awards, boasts comprehensive online documentation and is used by most Java developers. So, what could a book say that is already not available online?" Read on for Kumar's review of Ant: The Definitive Guide.
Ant The Definitive Guide
author Steve Holzner
pages 316
publisher O'Reilly
rating 8
reviewer Pankaj Kumar
ISBN 0596006098
summary Complete Build Management for Java with Ant

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.
This discussion has been archived. No new comments can be posted.

Ant - The Definitive Guide More

Ant - The Definitive Guide

Comments Filter:

  • Make file (Score:2, Informative)

    by alex323 ( 901730 )
    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!

    • Re:Make file (Score:3, Informative)

      by Cryptnotic ( 154382 ) *
      I hated that about it. You can't make a file using just a text editor unless you want to break your fingers on the shift, < and > keys.

      • I've fuond enough samples in the bundled set of Ant docs that I only have to customize Ant scripts, not create them.

        • Re:Make file (Score:5, Informative)

          by codegen ( 103601 ) on Friday July 22, 2005 @05:44PM (#13140299) Journal

          Just like JCL(IBM's job control lanaguage). Read the New Hackers Dictionary description [outpost9.com] of JCL. An excerpt:

          "Most programmers confronted with JCL simply copy a working file (or card deck), changing the file names. Someone who actually understands and generates unique JCL is regarded with the mixed respect one gives to someone who memorizes the phone book"

          About sums up my opinion of ANT.

          • Re:Make file (Score:3, Insightful)

            by jarich ( 733129 )
            Then I respectfully submit that you have very little experience JCL or Ant (or both).
            • Perhaps that was a bit hasty...

              Let me instead ask you... do you work with Java code? If so, how do you build your projects?

              Do you let your IDE do all the work? Or does your company IT department handle all compiles? Or...?

    • Re:Make file (Score:2, Insightful)

      by truckaxle ( 883149 )
      Whoever decided to use a tab as a delimiter should not be allowed to die a natural death. This "feature" has cause countless hours of loss productivity. At one time the make processor gave some obscure warning on the missing tab and left you scratching your head for hours.

      • Re:Make file (Score:3, Insightful)

        by Baki ( 72515 )
        people should use a decent editor such as emacs. its make mode highlights the tabs so you can readily see what's up.
      • Being in the Mac OS X world, there's a big chasm between the practices of tab-delimiting and space-aligning data.

        Unix originated the idea of the tab-delimited file as a simple way to delimit fields and records (with a character that was unusable in the field data). But it quickly fell from favor because text editors were inconsistent when 1-byte of data did not equal 1 space on-screen. The tools failed them so they abandoned tab-delimited file formats.

        Oddly enough, the ancient Mac OS (pre-OS X) users h

    • Comment removed based on user account deletion

      • Re:Make file (Score:3, Insightful)

        by jarich ( 733129 )
        Yeah, but I can ~see~ the missing angle brackets! And with proper indentation, matching in XML elements is trivial...

        Of course, most people I know who hate XML write their XML on a VERY long lines, with lots of elements jammed in together, and then they complain that it's hard to read.


      • Yep and just about every XML editor/parser out there - including Ant itself - will scream if it's not a well-formed document.

    • Yeah, since xml is so great [xmlsucks.org] and we are not creative enough to develop a better format than xml or makefiles.

  • mwuhahahaha (Score:3, Funny)

    by sargosis ( 807169 ) on Friday July 22, 2005 @04:02PM (#13139328) Homepage
    So, what could a book say that is already not available online?"

    Nothing, you have to read it.


    Sorry, i just had to...

  • Ant life cycle... (Score:4, Funny)

    by op12 ( 830015 ) on Friday July 22, 2005 @04:04PM (#13139352) Homepage
    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 [rinconvitova.com]
    • 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 book
      • Lots of vital information for various apache projects can be found on the wikis. It all usually comes down to finding people who write the docs. But I must admit, the current doc development cycle of using forrest and sending in patches is not very beginners friendly, while writing docs is the best thing for getting started for beginners to get into a project. The apache projects are in a chicken egg situation, documentationwise, I think many of them should point out their respective WIKIs more clearly and

    • Re:Only two words necessary (Score:2, Informative)

      by Anonymous Coward
      Maven has serious issues as eloquently explained by Hani [jroller.com]. Be sure to check out his newest article on mergere [jroller.com], the company that attempts to support maven.
  • 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 $$.

  • Necissity if you use Ant (Score:2, Insightful)

    by Anonymous Coward
    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 re

  • Frankly, I don't care about building Java. (Score:5, Interesting)

    by david.given ( 6740 ) <dg@cowlark.com> on Friday July 22, 2005 @04:21PM (#13139529) Homepage Journal
    I want to build generic programs. Java, C, Pascal, Occam, COBOL, shell scripts. This is because the applications I need to build tend to be a mixture of various different paradigms: little tools that are built to produce data massagers that convert offline data into compilable data; metacompilers like yacc and bison; XML preprocessors like xslt; traditional C or C++; documentation builders like Javadoc or WEB... I can't find anything that will handle all this cleanly.

    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 [sf.net], 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.

    • Actually, make scales pretty well if you have a single make process read a bunch of files with "include", possibly recursively. It handles having different rulesets if you use static pattern rules. The only problem I haven't been able to solve effectively in my use of make is getting it to recheck dependancies after recomputing them (and I haven't figured out how to pull together the linking requirements of libraries and get each one listed once in the necessary order).

      The main thing is that you really wan
    • "I want to build generic programs. Java, C, Pascal, Occam, COBOL, shell scripts."

      Well, nice if you to post your complaints in a forum about Ant and Java, then.
    • Any suggestions?

      Prolog.

      No, I'm not kidding. Solving complex dependency trees is what Prolog's *for*.

  • SCons (Score:5, Informative)

    by Chmarr ( 18662 ) on Friday July 22, 2005 @04:28PM (#13139595)
    If folk want something better than make, but don't want something so Java-centric. Have a look at SCons [scons.org].

    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 :) (Yes, SCons handles Java as well as C or C++).
    • In your experience how stable is SCons? Their website gave me the impression that it is a beta software.

      • Re:SCons (Score:5, Insightful)

        by Chmarr ( 18662 ) on Friday July 22, 2005 @06:35PM (#13140655)
        At this time, pretty damn solid. Yes, it's 'officially' beta, but they're just polishing the edges now.

        The only problems I've run into so far relate to SCons being a little too clever for it's own good, and not 'neatly' letting me do things that make could do. I worked around them, once I understood SCons better

        For example, SCons lets you generate static and shareable objects using 'StaticObject' and 'SharedObject', and will 'do what's necessary' to make that work on your platform. Eg, under *nix, it will add '-fpic' to SharedObject. It will also refuse to let you add a StaticObject into a SharedLibrary. Which in most cases is just what you'd want to stop happening, but... if you KNOW that in a particular case it will work, then SCons is getting in the way. Eg, we wanted a .a full of .so files that were compiled with -fpic, and then add that whole .a into a .so. Perfectly valid, but odd, and SCon's structure didn't let us do that easily.

        But... there's workarounds and they all 'make sense', but require a little more SCons knowledge. The mailing list is quite active and helpful, though.

        If your project is straightforward (even if it's HUGE), then there's no problems at all.

    • Scons keeps track of dependencies using MD5sums on the tail nodes.

      I'm not familiar with SCons, but this doesn't compute. The problem with make isn't with recognising changed files, it's identifying dependencies in source files (hence 'make depend').

      'make clean' is an artifact of changes to the build environment that are not properly represented in the dependency graph. Looking at SCons, it appears the authors have a few neat ideas, but I fail to see how a different management tool will help in working o

      • Re:SCons (Score:4, Informative)

        by Chmarr ( 18662 ) on Friday July 22, 2005 @06:48PM (#13140752)
        I glossed over some of the features, and reasons for them, so let me explain.

        The 'md5sum' thing ensures that you're not relying on timestamps. Especially important if you're dealing with several machines that might not have their clocks synchronised perfectly. Furthermore, the 'signature' of any of the build nodes is the concatenation of the MD5s of all it's dependencies, PLUS the command lines to generate that node. Change ANY one of those, including changing any compiler flag, and the signature doesn't match, and the node gets rebuilt.

        SCons does its own inherent dependency checking, and caches that, too, plus recording the signatures of all the files needed to generate that information. If any of THAT changes, it will re-get dependencies, and then use the result to determine if a node needs to be rebuilt. This, plus the previous part, makes 'make depend' unnecessary. SCons always gets it right, which cannot be said for Make, or (I think) even Ant... (We currently DO have problems with Ant after a 'cvs update'.). I'm pretty sure that you can make your '.depend' files depend on the files that were used to generate it, but the solution [gnu.org] for that for Make (unsure for Ant), is UGLY. SCons handles it all automatically.

        SCons also handles cross-platform builds. It's actively tested under *nix and Windows.

        Really, if any product deserves to be called a 'category killer' for this category, it isn't Ant, it's SCons.
    • If you are using scons to do what it claims out of the box, then you might be fine. But, if you try to extend it like it should be able to, you'll run into problems.

      Scons is also confusing if you want to do anything more than make c files out of one directory.

      Also, the community surrounding it is insufficient to provide full support. Go in with the knowledge you're going to have to open the covers to see what's inside. (ie. you have to be good at Python, even though they claim otherwise.)

  • JUnit? (Score:2, Interesting)

    by FranTaylor ( 164577 )
    One of the nicer features of ant, one that doesn't seem to be mentioned, is its JUnit integration. There is a very JUnit reporting mechanism built into ant. It wasn't exactly what I wanted, but with a fairly small modification (superclassing, no actual code mods) I was able to get it to work just as I wanted it to.


    Hey, make fiends, try this: add new functionality to make, extending its syntax. PITA, you say. It's very simple with ant.

    • ant made a mistake wrt junit. they include the ant task as part of the ant distribution (in the ant/lib folder), but they don't include the junit.jar. thus, a _standard_ install is not able to do junit testing.

      you don't have access to always go around putting extra jars into the ant lib folder or even the ~/.ant_lib or whatever private folder ant also looks at for its main classloader. you can nearly assume you can do the following:

      cvs co projectname; cd projectname; ant

      that's about it.

  • Additional Ant Goodies (Score:4, Informative)

    by Robotron2084 ( 262343 ) on Friday July 22, 2005 @04:47PM (#13139782) Homepage
    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.

  • Forgive my ignorance... (Score:4, Interesting)

    by Kr3m3Puff ( 413047 ) * <meNO@SPAMkitsonkelly.com> on Friday July 22, 2005 @04:50PM (#13139803) Homepage Journal
    Can someone explain to me the difference between Ant [apache.org] and Maven [apache.org]? 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.
    • Here are two URLs that explain Maven better than I can:

      Basically Maven is an extra layer on top of Ant. Or another way of putting it is that Maven is way to program Ant in an XML based language called Jelly. Maven has the concept of repositories and versions, so that you can say that a particular jar file requires specific versions of other jar files in the repository. If yo

    • Maven sits at a higher level than Ant, where Ant is really just a system for defining targets and dependencies between targets, Maven abstracts build logic across all project by way of plugins. So, instead of telling your 10 separate web application projects how to compile, test, and generate a WAR file, you simply describe each project in a common Project Object Model (POM), you then invoke something like the WAR plug-in, which takes your project's model and generates a WAR file. Long story short, in Ant
    • Ant: toolkit for building, declaratively (e.g. say "please compile/javac these stuff, and how" instead of specifying "javac -classpath ... -d ... File.java"

      Maven: a framework or skeleton your build will follow, declaratively. "This is the source tree..."
  • There is a port of Ant to .NET available from here [sourceforge.net]. 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:

    <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

  • Ant is simply not a Make replacement (Score:4, Insightful)

    by Zenin ( 266666 ) on Friday July 22, 2005 @05:26PM (#13140125) Homepage
    I know Make. Make is a friend of mine. Ant is no Make.

    Ant can automate Java builds slightly better then a .bat or shell script...but that's sadly about where it ends.

    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 .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 has no built in dependancy system

      No dependency system? Whatever do you mean? When writing Ant files you configure dependencies between Ant targets. A target in turn has a number of tasks that do the actual work. The if or unless attributes in a target can be used to decide whether to execute the tasks within a target or not. So if you sometimes don't wish to execute a javac, zip or copy task you should place that task in a target with either the if or unless attribute.

    • Ant does have a dependset task and an uptodate task for explicitly defining dependencies, in addition it has the condition task to bind several dependencies together in a logical manner.

      But still, ant is no make. It's not ant's fault, but more a fault of the underlying reason that make is both powerful and problematic. Make leverages the power of it's shell and all the utilities that have been written explicitly to make shell scripting possible. Make (by itself) doesn't do a lot except call a bunch of p

  • Ant is a Misapplication of Technology (Score:4, Insightful)

    by aldheorte ( 162967 ) on Friday July 22, 2005 @06:01PM (#13140420)
    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.
    • Somewhere in the Java code base are the seeds of the first computer virus to ever cross from the silicon to the meat brain. It's the only conclusion I can come up with to explain all the terrible design in just about every significant Java project I've seen so far. Ant is merely the tip of the iceberg.
    • Dude, you're wrong. As far as appropriate uses of XML goes who do you think would be the authority on that? The W3C who created XML? James Clark? Dave Pawson? People from SGML?

      The answer is that all of these groups and people created a XSLT - a functional XML programming language. That's right, the people who produce the XML spec also produced an XML programming language, just like Ant.

      XML is a meta-markup language, a series of rules, and you can represent data files as much as you can represent progra

      • The authority on it is what constitutes the simplest solution to the problem (of builds in this instance). Introducing the markup overhead of XML for no practical benefit and essentially requiring programming in what is supposed to be a *configuration* file is certainly not that simplest solution. In this manner, XSLT, as well, falls down since much simpler and more powerful functional programming languages exist.

        The W3C is not an authority on anything. They are more of an idea reviewing and specification

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close