Slashdot Mirror
Java Development with Ant
Pros:
- Excellent coverage of optional Ant tasks
- Good division of beginner, intermediate and advanced content
- Thorough discussion of how to use Ant to solve a variety of software configuration management situations
- Shows how to use Ant for tasks outside of typical configuration management roles such as the automated code generation of EJB and Application Server deployment descriptors
- Shows how Ant helps with a variety of software development methodologies including XP's suggested best practices of continual integration and JUnit testing
- Catalogs IDEs that integrate well with Ant including my personal favorite, Intellij's IDEA development environment
Cons:
- Some of the examples could have benefited from more detail. For example, the section on the PropertyFile task could have shown how to solve the problem of platform specific path separators in Java property files.
- At the time of this review, the book's accompanying website was a bit meager. For example, a comprehensive list of Ant on-line resources would have been helpful.
What the book offers
I consider myself an intermediate Ant user and when books on Ant first appeared I thought they would add little to the excellent free documentation and examples readily available. With its clean, straight forward syntax and structure, Ant has a low of cost of entry, and being rooted in Java and XML it is extremely flexible and extensible. I found Ant refreshingly easy to use as part of a configuration management system that included continual integration and a unit testing strategy. It was much better suited for Java development than the tool I previously used which was make. So when I agreed to do this review, I was skeptical that I would find the book useful. However, the book proved to be rich in valuable information that is well organized and clearly presented. Java Development with Ant, written by Erik Hatcher and Steve Loughran who are both committers to the Apache Ant project, is a great resource for anyone wishing to learn how to integrate Ant into his personal set of best practices for software configuration management solutions.
Coming to the book as a long time Ant user, I was glad to see that it offered material appropriate for others than just those approaching Ant for the first time. The book is divided into three sections each of which could probably find a niche as useful (and thinner) separate book: Learning Ant, Apply Ant, and Extending Ant. Only the first section of the book is devoted to first-time users, or those Learning Ant. The reminder of the book is about Ant in action. It covers an interesting variety of third-party Ant tasks, various ways of applying Ant to software development projects, and an in-depth section on how to extend Ant writing your own Java classes.
After a short but helpful introduction to the general topic of software configuration management, the first section, Learning Ant, launches into a thorough explanation of Ant's fundamental concepts and operation. JUnit test integration is treated as part of of the basic operation of Ant, which I was happy to see because unit testing should be a fundamental part of any software configuration management process.
Despite having used Ant on a number of projects since the summer 2000, at no point have I had to become truly expert with it in order to solve the wide range of software configuration problems I encountered. This is because Ant is easy to use. Typically, I figure out what I want the software configuration management to do, and then look for Ant examples that I can easily tweak to get the job done. I think it is a great credit to the Ant and its designers that I can do this successfully. Even though I've had this success with Ant, the introductory material filled in some of the gaps I had in my understanding of Ant's operation. For example, I was introduced to the PropertyFile taskdef which up until then had escaped my notice but which solved a problem for which I previously had a less elegant solution.
The most interesting part of the book was the second section that talked about a variety of Ant add on programs (called taskdefs) like Middlegen (an EJB descriptor tool) and XDoclet. XDoclet had been on the periphery of my radar for a while now, so I welcomed the book's thorough discussion of it in both a general and Ant specific sense. In addition there are helpful chapters devoted to using Ant as an aide to production deployment, web site generation including the compilation of JSP pages and the automatic generation of EJB descriptors. There are also chapters on working with Web Services using SOAP and a section on how Ant can be used as part of a continuous integration process complete with email notification. There is even a section on using Ant for Java projects that have a native code component. (Ant can be used to compile native code and the book shows how it can be helpful in dealing with the complexities surrounding JNI.) The book works well as a reference text. There's no need to read it from cover to cover in order for it to be extremely helpful.
The third part of the book also looks interesting, but it is intended for a more hardcore audience than myself. I've been fortunate to find ready made solutions for all the configuration management services I wanted to provide my clients. So, learning how to extend Ant has never been an issue. Every time I think I might have to develop my own answer, I find that someone else has already beaten me to it. Such is the nature of successful Open Source projects. However, I am glad this section exists, because I am sure at some point I will use it myself or refer a student or client to it.
The book even has some material on using Ant outside of the context of Java. Not having much experience with these technologies, I didn't pay close attention to these sections. (I am sure I'll be amused when I encounter my first .NET project that is using Ant for its configuration management solution).
In closing, if you are more than casually interested in software configuration management for Java projects then I recommend this book with enthusiasm. Beginners will be up and running with Ant in short order, while the book contains many interesting and useful nuggets for more experienced Ant users.
Ant on the web
- The Ant Project -- be sure to see their resources section.
- Ant FAQ at jguru.com (moderated by the book's co-author: Erik Hatcher)
- Ant forum at jguru (moderated by the book's co-author: Erik Hatcher)
- JUnit: A regression testing framework written by Erich Gamma and Kent Beck. It is used to implement unit tests in Java.
- CheckStyle: A development tool to help programmers write Java code that adheres to a coding standard.
- Middlegen:A general-purpose database-driven code generation engine.
- XDoclet: An extended Javadoc Doclet engine. It's a generic Java tool that lets you create custom Javadoc @tags and based on those @tags generate source code or other files (such as xml-ish deployment descriptors) using a template engine it provides.
- Intellij's IDEA "Develop with Pleasure" with this award winning Java IDE featuring full Ant integration that Marin Flower says: has succeeded in really moving forward the state of the art...
- The NetBeans and Eclipse Open Source IDEs also integrate nicely with Ant.
... the Java equivalent of make and makefiles. (...for those that don't know. They really didn't give a capsule explanation in the review) I personally like to develop java from the commandline, and Ant's conditional compilation (only compiling files that have changes) saves tons of time. Not to mention that it is quite useful in rolling out and configuring products. Even if you use an ide like Forte, it would probably be a good idea and head to the Ant page and see what is all about.
Also, it has become somewhat of the defacto standard in open source Java development.
Why, o why must the sky fall when I've learned to fly?
Amazon link
Just trying to save people some cash.
FYI if you don't want to buy b/c the patent issue I have to disagree. If patents are legal there is nothing wrong with following the law. If you don't like the law get off your rear and try to get it changed. (Me i'm too lazy, so I'm trying to inflame you into action!)
The Ant front page deals with the issue of makefiles:
--------
Why another build tool when there is already make, gnumake, nmake, jam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.
Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.
Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.
Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform -- to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an task that allows different commands to be executed based on the OS that it is executing on.
--------
To this I would add that it is not only a standard amongst open source IDEs for Java but practically all major commercial IDEs support Ant as well.
There is the little problem about tabs and spaces being rendered identically by most software but meaning very different things to make. The authors of make figured out pretty early on that this was a big mistake, but they didn't change it because they didn't want to disrupt their installed user base. Their installed user base at that time was approximately eleven users. If they had taken the bull by the tail and faced the situation, we wouldn't be having this discussion today.
I'm a wimp. Can't read what I can't see.
With make files, I can keep everything in one directory (I dislike having a src directory). With make files I can run ispell (I don't know of a spell checker I can use with Ant.) With make files, I can upload to my web site using scp (Is there a Java scp?)
You might want to switch to Ant to make building on different platforms easier. My make files work on Linux, Mac OSX, and Windows with Cygwin, so I don't feel too limited.
What everyone seems to be missing is that ant is far more than simply a build tool. Sure, ant does conditional compilation. But it also allows you to do things like automated JUnit testing, automatic formatting of test output, fixing of issues in source such as tabs, spacing, and end of lines, etc, etc. A well put-together automated ant build process can checkout and compile all of your sources, run all of your tests, package them in the necessary jars, build your installers, upload them to your servers, and e-mail all you developers the results of the process. That's ant leveraging off of other tools (like whatever installer you use), but that's what it's capable of.
Adam Fisk
If you ever write a book (it's worth trying,, just not while having a full time job as a software developer), you'll understand why books are written as if the author was asleep; I think I only got 6 hours sleep for 4 months in row, it was brutal.
.net. In the bookshop you should also scope out ch11, Xdoclet, ch12, ch13 'xml', and maybe ch18, production side deployment. Its not often a book on java has a chapter criticising the many j2ee implementations for all being different, or operations teams who cal up engineers at 3am whenever they get an error message they dont understand, but in that chapter we do it :)
I can also see your prejudice -I've read the other two ant books and I dont thing they bring enough to the table above the Ant docs. They have a better introductory guide, but once you know ant, that's no longer useful. We wrote ours assuming you have the ant docs open in a different pane of mozilla from the JDK docs, and added stuff that isnt in there. And we fixed ant as we went along when we found problems: you can guess when we wrote chapters by looking at the ant bugzilla entries.
My recommendation would be have a look at your local bookshop, sit down in a corner with a coffee and your laptop, and read through bits of it. Pick a chapter related to a project you are working on.
Up on the manning site we have posted a couple of chapters. Ch4 is about junit; I assume you know that already. Chapter15 shows how to build apache axis based web services and how to interop test against
-steve
(pet peeve: books about OSS projects that dont add to the docs and whose authors didnt contribute anything to the project, not even bugreps)
Ha! this is funny.
Yes, there is a slow boot time as ant parses the xml file. This is a fault of parsing everything before executing; when a rewrite eventually gets done this will go away. and for short things like the 'clean' target in a big project, this shows.
but what if your project is javac stuff, junit test it, deploy it, httpunit test the deployed? There its the stuff you run that is the slowness. Ant can help here by running stuff in VM, but the bottlenecks really are the # of tests you run, and how long it can take for JSP pages to compile. At least with a fully automated process you can do other things while the testing and deployment goes on.
Also, can I point you to the myrmidion prototype underway in the ant-dev group as one possible nextgen ant. Faster and more coherent.
-Steve Loughran
ps. point taken about debugging. I think ant-based projects are getting so complex we need to start doing better. One think make has is the -n option to show what happens without doing it. Ant doesnt have that as it is the tasks that do dependency work, not the core engine.