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.
I tried to get the little guys to write some jsp for me, but they wouldnt go onto the keyboard without me spreading honey on it.
It's good that there's a book on how to get them to do what you want.
Be you Admins? nay, we are but lusers!
... 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?
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. Everything else you have to cusotmize, build custom, or just skip Ant altogether.
Still, I have high hopes for the next big version of Ant where they plan to fix a lot of these problems.
Ant is basically a cross-platform scripting language that is really really weak. Really weak. I'm much looking forward to AAP by the programming god Bram Moolenar. This system is the logical extension of make into the 21st century.
http://www.naildrivin5.com/davec
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
I've always used makefiles for my Java development and it works very, very well. Make is a proven product, has a well-defined, well-documented syntax and for the most part, is very easy to read (while Ant's XML mishmash is a mess).
>>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.
Also, there is little consistency in Ant's syntax. Are they planning on creating a schema or a DTD for Ant so I don't have to perpetually debug my scripts by trial and error? What about a debugger? Ant's getting more and more complex as a scripting engine and it's approaching the point where a debugger would really be useful in some cases.
Your pizza just the way you ought to have it.
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!)
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.
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.
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.
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.
Yay, I couldn't have said it better myself. I'm not an ANT trasher - ANT was a good attempt at replacing "make" with an XML-based description, and ANT has some pretty nice extentions.
Alas, now I see that "make" is pretty darn good at what it does. And I see that ANT's XML-based solution to "make"s issues is far less than elegant.
Our company is doing a mixture of Java and C++ so we are using make. I came across a fantastic conditional compiler written by some developer at sun.. JavaMake It can be easily integrated with Ant and it evaluates the bytecode of the updated files to see what signatures have changed. It then recompiles anything using those signatures if they weren't changed as well. It works *wonderfully*. The only limitation is compile time constants. If you change the name or type of a constant, it has to recompile the whole project because the Java bytecode only has the substituted value, not a reference to the variable.
Check it out. It can save a *lot* of time.
All I wanted was a rock to wind a piece of string around, and I ended up with the biggest ball of twine in Minnesota
basic XML is readable and editable, but they are throwing so many kitchen appliances into XML (namespaces, XPATH, etc...) such that it is practically unreadable and uneditable. There are so many "standards" for XML right now that it is practically impossible to follow all of them.
"The area of penetration will no doubt be sensitive." ~ Spock
When you have intelligent IDEs like IntelliJ's IDEA. I understand what a make file is from my c++ programming, and if that's essentially what Ant does, I have no use for it. IDEA automatically only compiles the files I've changed, or if i want, rebuilds everything. Not to mention it obviously recurses into every directory in my project and compiles everything. So in light of all that, why would Ant prove of any use to me if i don't use command line java writing tools?
- tristan
Id rather have inconsistant syntax and a powerful, efficient build system than the consistant syntax any day.
Huh?
You must like Visual Basic then. It has the most inconsistent syntax going. And it was built in an adhoc make-it-up-as-you-go fashion.
There is no excuse for sloppy syntax structure.
Take the time to make it right. Otherwise you end up with a mess of things the programmer has to remember, AND it becomes a nightmare to maintain.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
However it became burdensome so they dropped it. In 1997-8 there was no better place to buy (no pun intended). Their service was spotty but overall if you had a problem and were consistant in your communications it would be resolved.
The way they formerly did it was you faxed them a copy of the receipt (at the time from any retailer) and they would beat it by 10% or pay the difference!!! Pretty cool (although not a good business decision in the age of PriceWatch and Shopper.com).
These are the questions I need someone (or some book) to answer. Will this book answer them?
I'm old enough to remember when discussions on Slashdot were well informed.
Exactly right.
The XML mess is far worse than the tab issue.
Make files are much better once you get used to them. They are so much more terse you can follow what is going on. XML is a disastrous choice - it makes something which should be simple fucking awkward.
The cross platform abilities are kinda useful but not that hot. If you're doing anything non-standard you end up needing exec and then you have to deal with the same cross-platform problems as you would with make.
The superior dependency management in make means that well written make files are much faster as well as being much smaller and easier to understand.
http://rareformnewmedia.com/
I bought the book, and that's saying a lot because I'm very cheap. It's a great book that doesn't just teach you how to use Ant, it teaches you how to do lots of things with Ant, like build web services using the excellent Apache Axis, which can automatically create a web service from any Java class source file. It also teaches you how to use JUnit to do automated unit testing with Ant, how to use CruiseControl, etc., etc.
A lot of posters have complained that XML isn't very human-readable. I use and highly recommend a great little tool called Pollo. It has built in support for creating Ant build.xml files, as well as Cocoon sitemap files, XML schemas, etc. IMHO, it's got the best XML editing GUI I've found.
---------------------------------------------
SERENITY NOW!!!!!!!!!!!!!!!!
Really you mean Make+Autoconf+Unix is great, and who can argue with that?
But ant is nice because it is fully x-platform, from MacOS X, OS/400, Netware, Linux, Solaris, NT. Even Win9x, though that raises too many support calls.
Also it is nice because makes dependency model is tied to the local filesystem: its notion of 'needs doing' means dest file is older than source file.
Ant offloads dependencies to tasks, and each task has its own logic. The command talks stright to the database, knows about timestamps of dependencies over the wire, etc.
Sometimes make is better, because it adds dependencies to those dumb unix tools that just 'do' things. Its crufty to do the same in ant with tests and conditional targets. The other failing of Ant is that it doesnt necessarily scale as well as gnu make+autoconf does. We will have to work on that,
-Steve Loughran, co-author Java Development with Ant
This isnt an ant bug per-se. It is a java bug: no way of getting the permissions. "You have no use for that information", say Sun :-( . Actually, ant's zip task doesnt store permissions, so if it could detect them, then a bug would surface.
If you use the task, you can specify the perms on a , so the permissions on your tar distro is all set up. This even lets you create proper tar files on a windows box that doesnt understand permissions at all.
-Steve Loughran, co-author Java Development with Ant
wow, mod this person up. nobody has said nice things about me on ./ before.
Of my presentations, my current favourite is actually
The Wondrous Curse of Interoperability , where I get to criticise everyone's SOAP implementation, even the one I work, on, Apache Axis. Plus it has excellent mountaineering photos.
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.
Ant is not meant be a scripting language.
It is meant to be a declarative language to be interpreted by an engine; there have been multiple implementations of the ant engine (there are two in ant CVS), which can take the same XML declaration and build things because of it.
XML is a different issue. Yes it can be ugly, but compared to the secret tab characters in make, it is better. You can use XML editors (I use jedit) to edit it, and its easy to generate ant build files from higher level specification files using XSLT and other XML processing chains. Or vice versa: there are tools to take ant files and parse and navigate them, such as the IDEA, forte and jedit and plugins, or the vizant ant project visualiser.
Also look at maven
which is a high level wrapper around ant for real project work.
But thank you for your AAP pointer; i will look at it.
Steve Lougran.
I think an interesting point is that you are not restricted to compiling / configuring / running only your Java code with ANT. As an example I use ant to package and upload my PHP code to the web server, so its simply adding a tool feature on the IDE (editplus in my case) and clicking a button to set it off. So Ant can be a nifty tool in your toolkit.
I'm sure that with a clever extension one could write ant modules that compile other languages as well (and Im sure it's already been done).
What do you like about AAP's design? Why do you think it's going to be so good?
Find free books.
Sorry for screaming, but I hadn't seen that mentioned yet, and it's day two.
Perhaps it's possible to write ant scripts that execute as efficiently as make, but it must not be very easy to do, since I have never seen one.
It's really nice when you're in a compile/edit cycle if it takes only a few seconds for your compile to build you a new version of your system. If it takes a minute you'll be walking around the room getting a coffee, talking to your co-worker, and totally losing your train of thought.
Most make systems I've seen compile java code a zillion times faster than ant. Sure, ant can look deeper into the java files and compile just the classes it has to, whereas with make you frequently have to compile everything. But here's the trouble: make has already finished compiling everything before Ant has even parsed all of its XML.
I really would like to use Ant. It feels like it's the right thing to do. But I can't afford it, my time is too valuable, and it's too damn slow.
Also I find complex Ant scripts FAR more difficult to understand than complex make scripts. Sure for simple build scripts the "tab and space" thing may be an issue--but for less trivial applications these issues wash away and you start wondering where bits of information came from and with Ant you sometimes just don't know.
I've seen Ant scripts break in ways that were not obvious to anybody, and took hours to debug. I've never had such trouble with make unless I was trying to do something brutally stupid with it.
Maybe I'm wrong about all this. I sure hope so, because I would like to have a good Java centric tool. My main concern is that Ant sucks, and yet it's established enough market share that it's locking out further innovation in the area.
I really think Ant blows.
Nice straw man attack asswipe...
Number 1, we are not talking about programming languages, but build systems. Whine all you want, it's still better than the other major build system 'make'..
Number 2, if you have ever used Ant you'll know that these so-called inconsistancies are relatively minor and many get fixed with each new release. Clearly, you've never used Ant...
Since I started using Ant on projects, I've actually found them much easier to maintain, since the Ant script usually doesn't change, dick head, the code it compiles, jars and deploys does.
Nice try, troll
Never by hatred has hatred been appeased, only by kindness - the Buddha
Holy shit, just because XML is easy to read and write by hand doesn't mean it should be...
My point was that XML documents are easier for a program to parse (given the abundance of Sax and DOM parsers available in almost every language). Just beacause an XML document is large and complex for a human to read doesn't mean a program can't read with great ease.
So complaining that it's harder to write by hand than property files is crap because if you had any brains, you'd use an XML editor (like the ones built into Netbeans and just about every other IDE or XML Spy etc).
Reading a spec and using this stuff in the real world are 2 different things...
Never by hatred has hatred been appeased, only by kindness - the Buddha
Ooooooo, so cool, calling me pompous and an ass in the same sentence....
You don't need to edit Ant's XML by hand, Netbeans, IntelliJ and a few others have nice GUI's for doing that...and even if you do, it's not that hard.
Put your real name down next time asshole, so I can put you on my foes list...
Never by hatred has hatred been appeased, only by kindness - the Buddha