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.
javac -d classes `find src \*.java -print`
http://www.naildrivin5.com/davec
Ant sucks. But its the least sucky option. The syntax is very inconsistent, and there's a lot of things you can't do easily (i.e. control flow). But for 90% of a build process, Ant will do what you need out of the box.
First you say "it sucks" then you say it works 90% of the time. Those seem contradictory (to me anyway.) What areas have you found Ant to be lacking in that lead you to believe it sucks?
Repeat after me:
;) ) because, since it's an xml document, I can add elements and tasks by right clicking and selecting "Add".
;)
"XML is not meant for humans to read, XML is not meant for humans to read..."
XML is way of structuring information so it is easy for software to parse and read, not people. By the same token, it's also not meant to be typed by hand (although it can be). I use Netbeans 3.4 to generate and create my build scripts (an all my other java development
Pretty easy. Way easier than make and makefiles.
Sure the syntax is a bit inconsistant, but that's mainly because Ant growns by incorporating lots of externally created custom tasks into the base. It also gets released fairly often so there isn't a lot of time to refactor those new custom tasks to make them "look" like the old ones....if it ain't broke, don't fix it.
No matter what, the bottom line is that Ant makes Java development easier, faster and more manageable. Id rather have inconsistant syntax and a powerful, efficient build system than the consistant syntax any day.
BTW, If you are so disappointed with the way Ant is made, download the source, fix the "problems" you see and contribute it back...it is, after all, Open Source
Never by hatred has hatred been appeased, only by kindness - the Buddha
>>The book is divided into beginner, intermediate and advanced sections, which makes it appropriate for a variety of audiences.
It sounds to me like it's equally UNappropriate for all audiences. If I'm a beginner, I want a whole book for me, same with intermediate of expert. There are exceptions to every rule, but that model sounds better than I think it will work.
Actually, a strong business case for XML is that it IS human readable/editable. With a schema/dtd and a half-decent editing tool, xml can be very nice to work with. The nesting can get a little tough to manage, but overall the clients I've worked with like the fact that someone can get a reasonable idea of the config file without much support documentation.
This is not the greatest sig in the world, this is just a tribute.
>I've always used makefiles for my Java development
Make is great when you're developing on Unix. But try and move a makefile for a complex build from Unix to Windows and see how well it works. If you're using Ant, and you've done a decent job with your build.xml file and aren't calling too many "execs", the ant build is quite likely to work with minimum effort.
Ant is a cross-platform version of make, and by cross platform I mean the your build process can work the same on many evironments with little effort. Sure you can get gmake for windows. But then you'll need to get bash, cp, cat, rm, etc for Windows too.
I think you hit upon the key issue: cross-platform compatibility. Ant works pretty much the same across different operating systems, aside from exec'ing OS-specific commands (which should decrease in the future as mor e native ant tasks are added).
Make is super-powerful but infuriatingly incompatible even across different versions of the same product, such as GNU make.
Ant is easy to learn, after a brief period of warping your brain into their XML way of thinking, executes smoothly and quickly, and is infinitely extensible and very Java-friendly.
There's probably room for both tools in the universe but Ant is well worth learning and adding to one's bag of tricks.
it's = "it is"; its = possessive. E.g., it's flapping its wings.
One thing I always envisioned in a build/deploy script is the ability to successfully 'rollback' all the changes applied in case of a failure.
.tar.gz treatment, sent to the appropriate server by FTP, where it is later extracted through a remote console. All of this is done in Ant.
This is doable. Well - nearly, anyway. My team uses Ant to build and deploy our Enterprise applications. Essentially, we have Ant build our sources nightly. If everything goes ok, the whole deployment tree gets the
If there is a failure, I get a notification in my mailbox that gives me the Ant output. The server didn't get any updated files, so nothing changed. Simple.
Using Ant, we've been able to work with CVS fairly easily, and other built-in and third-party addons help a great deal. No, it's not make, but for our application which has ~1000 java classes and another ~1000 data and properties files, it just works.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Which is easier for humans to read?
s =one.html,two.html,three.html
host=myhost.com
Port=7876
Protocol=http
File
or
<Server>
<host>myhost.com</host>
<port>7876</port>
<protocol>http</protocol>
<files>
<entry>one.html</entry>
<entry>two.html</entry>
<entry>three.html</entry>
</files>
</Server>
Oh yea, which takes up more bandwidth too? XML May be nice because of its structured markup but plain key=value files (some people call them Properties files) are easier for humans and computers to parse and usually take up less bandwidth. Now, that's not to say that XML doesn't have its place but I think people over-use it. For instance, a three line config file that will only ever be three lines/properties doesn't really need to be XML, does it?
Now you repeat after me:
XML is also meant for humans to read, XML is also meant for humans to read.
The element type names (tags) hold a semantic value that makes this data representation nicer to work with. I would any day prefer working with XML like rather than a binary representation where same semantic value is missing. You can deduce lots and lots just by looking at an XML document with informative element type names. So far, the semantic value is for human consumption, but lots of research goes on in order to make the meta data usable for machines also.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Well the beauty of Ant is if it doesn't have everything you need you can build a custom Ant task very easily. I find it very flexible, it sure beats the hell out of make files and shell scripts.
What you've got to remember is that most large organizations do multiple nightly automated builds. If you're only using and IDE, it is difficult to automate this process easily. If you're using make system of some kind, it's as easy as creating a cron job.
-Ben Hale If I have seen further it is by standing on ye shoulders of Giants. -Sir Issac Newton
To address your second question:
... you sound like a one-man configuration team. So why bother? Unless you're unhappy with your make files, you should use the time otherwise spent migrating to ant, to fix a few more bugs, or to take the dog for a walk.
we've been using Ant for a year now in a JSP/EJB environment. At first we simply used ant to compile and run our unit tests. The junit and junitreport built-in tasks gave us the incentive.
After getting used to ant, we converted our JSP Makefile. And finally our EJB Makefile. So we migrated in a piecemeal fashion. (It's not a very specific answer, but there again, I don't have your make files in front of me.)
We still have other make files for non-java software which get invoked from ant, and for things which make handles better (asynchronous tasks for example). I don't plan on getting rid of them at the moment, and I'd never recommend ant for any other language, unless we're talking about a small number of native routines in an overwhelmingly Java system.
The ANT XML file format, far from being the clunky monstrosity mentioned by some people here, seems to encourage our developers to better structure their build tasks. It took me a bit of time to grasp the 'declarative' nature of the file format, but this is the very thing that forces the writer to concentrate on describing what the build should do, not how it should be done. (Insert here any arguments about declarative vs imperative -- in this case declarative is definitely better, and ant is more declarative than make).
On a personal note, although I've been programming for years and years on Unix, almost always using make, I very quickly took to Ant. For example, the fileset and patternset types, which used together allow me to clearly specify arbitrarily complex lists of file, are simply cleaner than calling find from within make.
Maybe because the ant tasks are predefined and have standard options, the newer developers in our company quickly find 'good' solutions (they also look on the web); in comparison, writing good make files requires IMHO more experience. Again, in our company, only the oldies with their strong C/C++ and UNIX backgrounds like using make, and more importantly the oldies are the only ones who seem to be able to write good (i.e. well structured, understandable and maintainable) make files. Since the newer developers appear much more happy with Ant, I don't see any reason to discourage them and I, in turn, am happy that the build files have fewer problems than would otherwise be the case.
However in conclusion, I wouldn't recommend that you change
Cheers.
This is nothing more than opinion - you offer no arguments whatsoever to back it up. I can't believe it got moderated to +5.
Personally, I'm not crazy about reading raw XML in general, but it's not difficult at all in the case of Ant buildfiles. The structure is not very complicated and using XML makes it easy to use a validating editor to check your build files (there are DTDs that work for simple buildfiles out there). This also means that it is easy to write tools to manipulate the build files (XML is easily scriptable and there are lots of parsers already available). Try writing a tool from scratch to deal with Makefile syntax in an hour or two - not very easy. Using XML also makes sense from the standpoing of being able to easily integrate new custom tasks into the tool - each new task doesn't have to invent its own funky syntax. So, I don't think using XML buildfiles is such a bad decision.
No, it's not. It's a build tool and deserves to be evaluated as such. If you're willing to make such blatantly false claims, I wonder how much you really know about Ant or about scripting languages.