Java Development with Ant

smarks writes "Java Development with Ant effectively shows the reader how Ant can be used as the foundation for the most complex Java software configuration solutions. The book is divided into beginner, intermediate and advanced sections, which makes it appropriate for a variety of audiences. The book has a comprehensive survey of tools that can be used with Ant such as JUnit, CheckStyle, Middlegen and XDoclet Even the experienced Ant user will find these sections helpful. Overall, Java Development with Ant is an excellent resource." Read on for the rest of Spencer's review. Java Development with Ant author Eric Hatcher, Steve Loughran pages 634 publisher Manning rating 8.5 reviewer Spencer Marks ISBN 1930110588 summary How to use Ant to meet all (or most of) your poject's software configuration needs

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.

You can purchase Java Development with Ant from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Use campusi.com

[Anonymous Coward]

Use campusi.com, type in the ISBN number (1930110588), and you'll see that half.com and alldirect.com have it for $29.72 and $31.32. Every buck counts these days, you know!

and FP?

JUnit

[mr_gerbik]

I don't know about you guys, but all the fine Java ladies dig my JUnit.

-gerbik

Re:JUnit

[mr_gerbik]

oh please you are a slashdot no lady except maybe your mom (who is not really a lady anyhow) has ever seen your junit

Its possible that your Mom has caught a glimpse of my JUnit.. but its unlikely as it is always in her mouth.

-gerbik

Re:JUnit

[Anonymous Coward]

J-Lo JLo-ves Jour JUnit?

Re:JUnit

[Anonymous Coward]

www.davidlynch.com?

Well

[acehole]

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.

Re:Well

[Anonymous Coward]

"... 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."

Where else has this bizarre ant fetish had you spreading honey?

Remind me not to buy any used snorkeling gear from you ...

Re:Well

[GreggBert]

You just didn't specify the correct Ant "task".

biggest complaint about Ant

[Anonymous Coward]

Is that they made up the syntax as they went along - there's little consistancy. It's a mess of different tags even for similar tags. And I think XML sucks for the purposes of build processes. It's hard to read and a pain in the ass to type.

Re:biggest complaint about Ant

[Anonymous Coward]

s/different tags even for similar tags/different tags even for similar tasks/

Re:biggest complaint about Ant

[opk]

My main complaint is that it doesn't seem to be very good at working out all the dependencies properly so it rebuilds things which don't need it. But for things like putting together ejb,war files etc, it is a lot easier than make.

The XML tags never seemed to be particularly messy to me - I've seen a lot worse.

Re:biggest complaint about Ant

[GusherJizmac]

Yes, ant is really not much (and at times worse) than make for figuring out dependencies, and it seems unlikely to change, due to ant's structure. The XML is really an completely inappropriate use of it, and makes build files hard to work with and understand.

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.

Re:biggest complaint about Ant

[JohnnyCannuk]

Repeat after me:

"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 ;) ) because, since it's an xml document, I can add elements and tasks by right clicking and selecting "Add".

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 ;)

Re:biggest complaint about Ant

[Eric Savage]

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.

Re:biggest complaint about Ant

[Anonymous Coward]

Which is easier for humans to read?

host=myhost.com
Port=7876
Protocol=http
Files =one.html,two.html,three.html

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?

Re:biggest complaint about Ant

[Kingpin]

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.

Re:biggest complaint about Ant

[standards]

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.

Re:biggest complaint about Ant

[n3bulous]

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.

Re:biggest complaint about Ant

[RetroGeek]

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.

Re:biggest complaint about Ant

[joss]

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.

Re:biggest complaint about Ant

[RelentlessWeevilHowl]

It's alllll about the ratio.

If you have lots of real text, and tags scattered lightly around your document, then XML is easy for humans to read. Think about how readable HTML1 documents were.

If you have little bits and pieces of data embedded into a massive element hierarchy, then deciphering it becomes a chore. Ant's config file falls in that category. So do most web pages nowadays, it seems.

Remember that XML (and SGML) was designed so humans could write documents with it. Config files are really outside of its original domain, and it's no wonder it's showing some problems. That's why I prefer to use SXML syntax when I'm dealing with XML-as-dataformat. I find it's better tuned for that application.

Re:biggest complaint about Ant

[bluetea]

The XML is really an completely inappropriate use of it, and makes build files hard to work with and understand.

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.

Ant is basically a cross-platform scripting language...

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.

Re:biggest complaint about Ant

[steve_l]

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.

Re:biggest complaint about Ant

[bcrowell]

What do you like about AAP's design? Why do you think it's going to be so good?

Re:biggest complaint about Ant

[Bazzargh]

Repeat after me:

"I haven't read the XML spec, I haven't read the XML spec..."???

Section 1.1, "Origin and Goals":

"The Design Goals for XML are...
6. XML documents should be human-legible and reasonably clear."

Re:biggest complaint about Ant

[stevecoh1]

I don't think your example is a clearcut win for simple properties files. It sure won't scale.

suppose you have several servers to describe. Now your simple properties file has become a lot less simple. Notice how clumsy the comma notation becomes as compared to the nested-element notation.

server1.host=myhost.com
server1.Port=7876
serv er1.Protocol=http
server1.Files=one.html,two.html ,three.html ...

server20.host=yourhost.com
server20.Port=7877
server20.Protocol=http
server20.Files=four.html,f ive.html,six.html,seven. html,eight.html,isnt.this.line.getting.a.little.lo ng.html,html.html,etc.

Sorry, the more complex it gets, the better the xml version starts to look. It lets you see grouping and inclusion, much better than the properties file notation does.

Re:biggest complaint about Ant

[JohnnyCannuk]

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

Re: Re:biggest complaint about Ant

[JohnnyCannuk]

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...

Re:biggest complaint about Ant

[RetroGeek]

Name calling? That promotes discussion...

The point was that sloppy syntax is a BAD THING, giving VB as a prime example.

I have nothing against Ant. I just hate inconsistent, sloppy architecture.

Ant is...

[dubious9]

... 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.

Re:Ant is...

[GusherJizmac]

Ant doesn't do the conditional compilation, javac does. You can accomplish the same thing (for compilation) on unix with

javac -d classes `find src \*.java -print`

Re:Ant is...

[dubious9]

Hmmm... good point. It is, however, just easier to type "ant". Plus you can put more complicated rules into ant than you can easily achieve with javac.

Re:Ant is...

[GusherJizmac]

Oh, I wasn't saying use that instead of ant. Just pointing out that ant doesn't do the magic.

Re:Ant is...

[yog]

From the FAQ:

"In order to find out which files should be compiled, Ant compares the timestamps of the source files to those of the resulting .class files."

I'm pretty sure ant is smart enough to do "conditional compilation", or rather the compilation of only changed sources, since I think that's what the original poster meant.

Re:Ant is...

[pmz]

Ant is the Java equivalent of make and makefiles.

It really isn't an equivalent replacement. Although it is potentially more widely deployable than make, make is still much more powerful, because the /usr/bin/* tools are implicitly part of make's functionality. Having full control over I/O redirection thanks to a true UNIX shell environment is pretty handy, too.

Also, make is much more appropriate for offices that do development using more than one programming language (C, C++, Java, Lisp, etc.). It seems Ant is really a tool for Java developers (even though it is possible to kludge Ant's XML files for non-Java projects, I think it would get pretty ugly pretty fast).

Re:Ant is...

[FigWig]

Actually they both do....if you do an ant -v you will see that it only adds the files that need to be re-compiled.

Re:Ant is...

[arthurs_sidekick]

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.

I do use an IDE like Forte and in fact it has *great* Ant integration and you can even install the Ant documentation so it's available from within the IDE.

As a matter of fact, all the IDEs I've tried recently for Java do in fact make efforts to integrate Ant. (Eclipse, IntelliJ, even ... JDeveloper)

Re:Ant is...

[steve_l]

You are right; Ant does timestamp based comparison before deciding what to send to javac, or jikes.

But it does not (by default) do full dependency checking to force rebuild a file when a class it imports changes. The Task does that, (something we cover in chapter, 10 BTW). Even that task, which looks through the .class file to discover the imports, doesnt handle import of constants, as that isnt logged in the class files.

There is a lot to be said for clean builds using jikes, as that is reliable and fast.

-Steve Loughran, co-author Java Development with Ant

Re:Ant is...

[Dom2]

javac -d classes `find src \*.java -print`

That will fail nicely when you have too many java files lying around. You're much better off using xargs:

find src -name '*.java' | xargs javac -d classes

-Dom

Re:Ant is...

[Anonymous Coward]

ooooo hurry and tell apache so they can stop wasting their time on ant development...

Re:Ant is...

[steve_l]

I meant to say the task does proper depends checking; didnt escape the angle brackets before posting.

Ant sucks

[Trinition]

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.

Re:Ant sucks

[revscat]

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?

Re:Ant sucks

[Anonymous Coward]

use jam instead. it's not GPL free, but it is open source free.

As a comparison of jam vs gnu autoconf/make, I recently rebuilt freetype2 (which comes with jamfiles and makefiles). To build with jam, type "jam". to build with make, "./configure; make". jam was done building before configure was done configuring. Ok, so gnu autoconf sucks and does a LOT of unneeded testing. But even after configuring, jam was faster at building than make, and i'd rather edit the jamfile if I needed to than the makefile.

Re:Ant sucks

[PissingInTheWind]

Something that works 90% of the time _really_ _really_ sucks! Imagine your computer not booting 1 time in 10, or your web hosting being down 10% of the time... unacceptable.

Ant is definetely a case of 'Worse Is Better', as opposed to being 'The Right Thing'.

Re:Ant sucks

[DavidCole]

... Ant will do what you need out of the box.

You paid for a boxed version of Ant?! Sucker.

Re:Ant sucks

[revscat]

Apples and oranges. He said that it is good for "90% of the build process", not that it fails 1 out of 10 times.

Re:Ant sucks

[gss]

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.

Re:Ant sucks

[Anonymous Coward]

Actually, we used it on a project a few weeks ago and finally had to stop using it because it would not consistently compile modified java files. This was a serious problem. We finally switched back to using batch files with javac commands.

Re:Ant sucks

[PissingInTheWind]

Ant doesn't garantee that everything necessary will be recompiled, which I thought was why he said it was fine 90% of the time. In that case it was similar to my analogy. Ant _does_ fail x% of the time to do the right thing.

Re:Ant sucks

[Anonymous Coward]

You almost certainly did something wrong. We've never had that problem.

Re:Ant sucks

[stevecoh1]

All depends how you set it up. There are problems with ant, but for us, this is not one of them.

so

[Anonymous Coward]

where can anyone find a decent cup of cofe flaovored cofe without bugs?

Ant is for wimps

[doomdog]

... who don't know how to write a proper makefile.

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).

Re:Ant is for wimps

[Richard_Davies]

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.

Re:Ant is for wimps

[PosterChild]

>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.

Re:Ant is for wimps

[Lucas Membrane]

Makefiles very easy to read?

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.

Re:Ant is for wimps

[yog]

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.

Re:Ant is for wimps

[Anonymous Coward]

Ant is for wimps...who don't know how to write a proper makefile.

Incorrect. As ant's documentation says, make is shell-based and, as such, makefiles have issues when used on multiple platforms. Ant was created to relieve those issues.

Re:Ant is for wimps

[doomdog]

Yes, I've read the Ant home page, and I've seen their lame arguments. They only prove that those people don't really understand make or how to use it properly.

To claim that Makefiles are inherently evil just because the Ant authors are too stupid to handle the tab vs. space issue in makefiles just underscores their inexperience and ignorance. This is simply a syntax issue, and if you're going to use a tool (any tool), you need to learn the syntax. Besides, all it takes is a simple ":set list" in vi to sell you if you've got a tab there or a space :)

And the Ant people even admit: "Granted, this removes some of the expressive power that is inherent" in makefiles..

Why would you want to use an inferior tool like Ant just for "the abiity to be cross platform" ??? This is where their argument really falls flat. After all, Ant is a Java tool, right? Java is cross platform. You compile it on one platform and run it on many others -- you don't recompile your Java code on each platform! Where's the need for a cross platform Java build tool? This really doesn't make any sense at all.

Re:Ant is for wimps

[doomdog]

The only "issues" that Ant relieves are those relating to the inability of Ant's authors and proponents to understand simple makefile syntax.

Re:Ant is for wimps

[doomdog]

Yes, makefiles are _extremely_ easy to read and understand how the build process will take place, and which dependencies exist for a given component. When you're reading a makefile (on the screen or on paper), you don't really care about the space vs. tab issue -- you only care about the structure of your build process.

It is only an issue if your makefile doesn't work. Makefiles are not constantly edited, so once they're working, you leave them alone. When your dependency rules are properly written, you don't need to modify the makefile everytime you add or remove a class.

By the way, if your editor can't easily tell you the difference between a tab and a space, I suggest you get a new editor...

Re:Ant is for wimps

[Dan-DAFC]

Why would you want to use an inferior tool like Ant just for "the abiity to be cross platform" ??? This is where their argument really falls flat. After all, Ant is a Java tool, right? Java is cross platform. You compile it on one platform and run it on many others -- you don't recompile your Java code on each platform! Where's the need for a cross platform Java build tool? This really doesn't make any sense at all.

Well we use multiple platforms for development (Linux, NT, XP, Win2000) and Ant (plus xdoclet and JUnit) makes it easy for us to just get the code from CVS and have it compile and run straight off on any platform, no messing.

Re:Ant is for wimps

[doomdog]

So now I'm modded down as Flamebait for dissing one of the "sacred cows" (open source software) of slashdot? Figures...

Re:Ant is for wimps

[zapfie]

No.. you were modded down as Flamebait for posting flamebait. Not like it's anything to cry over.

Re:Ant is for wimps

[DeadSea]

I also use make files. Since my make files work on Linux, Windows, Solaris, and Mac OSX, I don't know how much more cross-platform you need. There isn't much else on which Java will run, so I'm pretty set as far as I am concerned.

As for the spaces vs tabs issue with make, it is no worse than trying to figure out the syntax of Ant build files.

I need to be able to do the following tasks:

1. pre-compile (Jflex)
2. compile
3. build html from templates
4. generate javadoc
5. spell check
6. build a jar file
7. tests
8. sanity check (download size correct on web page, etc)
9. upload using scp

Make can do them all easily and quickly. (Yes you can even set it to only compile what has changed, without running a new instance of javac for each file.) I don't know how to do the spell-check in Ant, and most of the other stuff is nowhere near as straight forward as in Make.

Re:Ant is for wimps

[doomdog]

Sure you can get gmake for windows. But then you'll need to get bash, cp, cat, rm, etc for Windows too.

No, that's not true. I can run my makefiles on Unix or Windows and I don't need "cat", "rm" and such on the Windows box... If you properly structure your makefile, you can avoid these platform dependencies.

For example, instead of embedding the Unix commands into your targets, like this:

target: dependency
rm -f myfile.ext you simply write it like this:

target: dependency
$(RM) myfile.ext

at the top of each makefile, I do an "include platform.cfg" which sets up RM to be "rm -f " for Unix, "del" for Windows, etc. Porting the build process to a new platform means writing a platform.cfg file ONCE and then using it on many different projects.. Most of my .cfg files were written many, many years ago and they still work perfectly.

Re:Ant is for wimps

[SofaKingdom]

Consider a development shop where not every programmer is running the same os but is developing the same codebase.... We all need to compile the code... Ant works well for this....

Re:Ant is for wimps

[doomdog]

The problem is that a lot of people here don't know how to differentiate between flamebait and a strongly held position....

Re:Ant is for wimps

[pmz]

Ant works pretty much the same across different operating systems...

As long as you deal with the Windows and UNIX pathnames well. Mixing Windows-based developers and UNIX-based developers in a project that uses Ant can still be a PITA if not thought out.

Make is super-powerful but infuriatingly incompatible even across different versions of the same product, such as GNU make.

It isn't difficult to write POSIX-compliant makefiles that work pretty much anywhere. Front-ending the makefiles with a shell script can encapsulate all the platform-specific stuff, such as command line options and the compiler to use. Again, it really is not difficult.

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.

The Java-centricity of Ant is its biggest weakness. Having to learn Ant for Java and make for everything else is just not good. I just use make for everything and my life is simpler for it.

Re:Ant is for wimps

[pmz]

But try and move a makefile for a complex build from Unix to Windows and see how well it works.

It can work very well. MKS and others provide a good make program and many of the supporting UNIX tools for Windows. Putting platform-dependent shell scripts in front of make encapsulates differences and makes supporting multiple platforms no more or less difficult than with Ant (the platform differences remain no matter the build tool you use). Also, using the non-standard GNU make extensions is simply not a good idea in any context, unless you can guarantee GNU make is installed in every context. Sticking to POSIX is much easier in the long run.

What would really be better than Ant, is a Java implementation of the MKS toolkit or something similar.

Re:Ant is for wimps

[Dan-DAFC]

Reminds of Maslow's quote: "If the only tool you have is a hammer, every problem begins to look like a nail" (or something similar).

Sure, you can solve the problem with make, but you have an extra step that's not necessary with Ant as all the tasks are written in Java and therefore cross-platform without requiring platform-specific configuration.

Make is great for development where the specifics of the platform are important but, in my opinion as a Java developer, Ant is better suited to Java development.

Re:Ant is for wimps

[pmz]

There is the little problem about tabs and spaces being rendered identically by most software but meaning very different things to make.

This really isn't a big deal at all. If you have spaces instead of tabs, Make fails in a consistent manner. Big deal. Just don't use text editors that insist on expanding tabs into spaces; those text editors are the problem, not Make.

Re:Ant is for wimps

[Raiford]

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.

Not to be trolling or anything but anyone using make would have those tools on his windows box anyway. First thing a true unix geek does on a windows box is install CYGWIN.

Re:Ant is for wimps

[bwt]

Ant IS the proper way to make a makefile. 'make' is obsoleted by Ant, which is the standard way to build java, period.

Ant is a proven product, has a well-defined, well-documented, and *validatable* syntax, unlike make. XML is self documenting anyway, and if you don't like the way it looks when you try to read it directly (?), write an XSLT to have it pretty print any way you like (for example to a nice HTML page with a table).

'make' uses its homegrown bizarre antiquated syntax that is NOT userfriendly, and suffers from an obnoxious reliance on whitespace (tab vs space is important). It is not self-documenting, nor can it leverage the large body of XML tools.

Ant has long since left make in the dust, and the 2nd generation tools like Maven, Gump, and Jelly, which all build on Ant, are the future.

Re:Ant is for wimps

[Make]

to compile Java files, jikes is the fastest and IMHO the best. But if you're doing more, like generating javadocs, whitebox tests or running other stuff to build your project, Ant is really good for Java stuff because it boots the JVM only once. Count how many times you boot a JVM for a full build with make. Java execution may be slooooooow, but starting a JVM ten times in a row is even slower.

Re:Ant is for wimps

[DeadSea]

My make file starts the JVM once for compile and once for javadoc. That isn't too bad. Make is very flexible and it is easy to customize this. I call javac on only the files that have changed, and yet I only call it once.

The basic idea is when make detects a java file has changed, it adds the file name to a list. When all the adding is done, javac is called on this list. My compile times are great and I have the full power of Make.

Re:Ant is for wimps

[zapfie]

Agreed.. but the difference, at least in my eyes, isn't so much what you say but how you say it. Using phrases and words such as "too stupid", "inexperience and ignorance", and "inferior tool", even if true, trigger 'flamebait' in a lot of peoples minds. You brought up some good points.. and I am pretty sure if you had avoided phrases like this, you probably wouldn't have gotten modded down as flamebait. For example, instead of saying "To claim that Makefiles are inherently evil just because the Ant authors are too stupid to handle the tab vs. space issue in makefiles just underscores their inexperience and ignorance.", you could say "To claim that Makefiles are inherently evil just because of the tab vs. space issue in makefiles is not a well founded argument in my eyes, since this issue is very easy to avoid once you have a little bit of experience with makefiles. I am curious how much time the Ant developers spent working with makefiles before they came to this conclusion."

Re:Ant is for wimps

[Make]

I agree, make (plus autoconf, automake) is more flexible, and I love it for C software. Ant doesn't have loops, and I really hate it for its IF/ELSE syntax. Still, for all of my Java software, I use Ant.

For make, you need a Unix environment (tar, gzip, make, a shell etc.) - which should not be required for a Java project which also needs its own platform. For Windows users, it's hard enough to install the Java platform, now deal with *another* platform only for building?

In the end, it's a question of taste.

Re:Ant is for wimps

[doomdog]

Point taken....

I do find it annoying, though, that people are quick mod something down, and extremely slow to post a response (mainly because a response requires thought and intellect [well, most of the time], while modding a post down is accomplished with a simple click...

Re:Ant is for wimps

[Anonymous Coward]

Just don't use text editors that insist on expanding tabs into spaces; those text editors are the problem, not Make.

ROFL!

yeah right, repeat after me: Make sucks.

Re:Ant is for wimps

[pmz]

repeat after me: Make sucks.

No. I was serious. Text editors that write to the file something other than the author intended are simply bad text editors. A tab is a tab, and a space is a space. Also, true tabbed indention is more text-editor agnositic and makes code more maintainable when it is worked on by more than one 2-space-tab 4-space-tab or 8-space-tab zealots. Spaces in place of tabs sucks. Make is just fine.

Re:Ant is for wimps

[zapfie]

Yeah.. I have seen that sentiment echoed by many in their posts, so you're not alone there.

Re:Ant is for wimps

[angel'o'sphere]

You can not mod and post to the same thread.

So modders tend to mod down what they dissagree with, as they allready choosed to mod and not to post.

angel'o'sphere

Re:Ant is for wimps

[rwald]

The Java-centricity of Ant is its biggest weakness. Having to learn Ant for Java and make for everything else is just not good. I just use make for everything and my life is simpler for it.

Chicken and egg. As a Java based tool, Ant was built by and for Java developers, and requires a Java Runtime Environment to execute the scripts.

It's not difficult to add support for compiling and executing stuff other than Java (indeed, there are many such "tasks" already available), it's just that if you are, for example, doing C/C++ development on *nix, you're less likely to be motivated to install, configure and execute a JVM in order to do the builds when make suffices.

Without question though, Ant is the defacto standard for open source Java builds, and rightly so.

Re:Ant is for wimps

[tpv]

You compile it on one platform and run it on many others -- you don't recompile your Java code on each platform!

Ummm... this is open source.
People download the source and modify and compile it on whatever platform they want.

Ant was specifically written to make it easier for people to compile Tomcat 3.x across a variety of platforms.
Distributing a set of makefiles that would work on all possible platforms was a nightmare, writing a simpler cross-platform tool was the best solution.

Unfortunately the users of that tool then went and decided that it suitable for all java development, and Ant was unleashed on the world.

Re:Ant is for wimps

[tpv]

Ant is a cross-platform version of make

No it's not.
It's a cross-platform tool that attempts to solve a similar problem to that solved by make.

Make is a hell of a lot more powerful than ant, but some people are willing to trade in that power for the perceived simplicity of Ant.

Re:Ant is for wimps

[tpv]

an extra step that's not necessary with Ant as all the tasks are written in Java and therefore cross-platform without requiring platform-specific configuration.

Bah!
The step's there, it's just that the Ant developers have already done the work.
Getting Ant to work on Netware was an amusing exercise to watch.

Ant isn't really anymore cross-platform that the solution suggested by the previous poster, it just hides the platform differences in a different place.

If he writes a platform.cfg and uses it for every project then the "extra step" is already done, and his solution is pretty much the same as Ant.

The book is divided

[automag_6]

>>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.

Re:The book is divided

[iplayfast]

presumably after reading through the beginner section, you will no longer be a beginner, and are ready for the interediate section.

Re:The book is divided

[FatherBusa]

I've been using Ant for a long time, and frankly, I can't imagine why anyone would need to go out and buy an entire book on it. For heaven's sake, if you can figure out Java, you can figure out Ant in under an hour. It just ain't that complicated.

Re:The book is divided

[steve_l]

I must take exception to your claim.

By the time you've read the first eight chapters you ready to either write your own build files, up to and including junit testing and deployment. So you can stop reading there if you want. But at that point you will probably need to look at one or two of the advanced topics, depending on what you want. Doing webapps? read ch12, Doing EJB? Ch 14. Soap? chapter 15.

The final section, extending ant sems a bit off topic to pure ant consumers, but we wanted to show it is easy to do, when Ant doesnt meet all your needs. Its easy to integrate other java code into Ant.

I Think there is still scope for a single 'Ant Internals' book that focuses on the code, explains the IntrospectionHelper, how tasks work, covers task testing, etc etc. But that is a niche product, you need to be a core ant developer to want that book. And we have the mail list and the source in that situation.

Re:The book is divided

[steve_l]

You can skip the first eight chapters then :)

You still might want to look at some of the advanced subjects, such as how to compile jni native code using , then run junit tests against it, how to set up cruise control or the gump to rebuild your code hourly, how to build C# clients to interop test your web service, etc.

If we'd stopped at the first section and added a rewritten task reference you'd be making a valid point. But we wrote the book as a supplement to the docs. After all, our hand is in the docs too, from Ant in anger or Ant Task guidelines (both mine), to all the little corrections we made to the ant docs when we wrote the book and disovered errors.

So use the docs -I think they are really good compared to many other OSS projects, and I am glad you like them. But I think you should still find value in Java Development with Ant. Erik and I really pushed the envelope in section two, doing stuff nobody had done in ant before.

Re:The book is divided

[FatherBusa]

So use the docs -I think they are really good compared to many other OSS projects, and I am glad you like them.

They are good and I do like them.

But I think you should still find value in Java Development with Ant. Erik and I really pushed the envelope in section two, doing stuff nobody had done in ant before.

And I shouldn't assume that the book is either a rehash of the docs or roughly equivalent to what any good hacker could figure out on their own. If the book really does "push the envelope" as you say, then I commend you for your efforts.

But honestly, there's so much junk out there (including junk from O'Reilly, which has produced at least as many doorstops as outstanding technical publications). And when I browse the titles at the local bookstore, I can see a pattern to the doorstops: most of them are about end-user applications that any idiot could figure out from a cursory browse of the docs.

And then I think to myself, "Geesh, I could have written that in my sleep!" I pick it up, and sure enough, someone did apparently write it while sleeping.

I'd love to pick up the Ant book and find that it was really taking me into the nooks and crannies of the tool, but it's hard not be predjudiced at this point. Way too much garbage out there.

Re:The book is divided

[steve_l]

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.

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 .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 :)

-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)

Re:The book is divided

[stevecoh1]

I am an occasional contributor to Ant and therefore, I suppose, an advanced user, and I found the book well worth purchasing.

Sure, you can learn the basics in an hour, and look at the docs to go deeper, but you miss stuff. Maybe you don't find the BEST way to solve your problem, you stop at the first hack that gets the job done. Somewhere down the line, as your project gets more complicated, you pay something for that approach. Eventually, you may want to tie up your random knowledge a little neater and move to the next level of understanding.

Not only that, but since Ant is an open source project, it is changing, and if your old stuff still works, maybe you won't notice the new stuff and continue to use methods that once were state of the art but are now inferior.

It all depends on your use patterns.

So it was with me. I just purchased the book and it has been worth the money I paid for it. I find that the best time to buy such a book is AFTER I have learned the basics, when I want to take my knowledge to the next level. There are many techniques for scaling ant to work with larger projects, for combining scripts so that they work both standalone and separately and all of these are touched on in the book (not as much as I would have liked, but they got me off the dime).

I do at least glance at the beginner chapters too. There are always one or two techniques, maybe new ones, that I missed. So a book like this lets you backfill your knowledge.

Of course there are a lot of books out there that are crap. This is not one of them. These authors did a great job.

Steve Cohen

Ant is not what I wanted...

[MSBob]

out of a build/deploy tool. 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. Say I tried to move a bunch of files from directory A to B and if one of them lacks write permissions it moves none of the files. This would help us come a long way towards a robust build and deployment strategy. Most install scripts are not only pretty poorly written (expect certain files to reside in specific locations) also in case of failure they leave an inconsistent mess of random files moved or copied around on your drive. We need a build/deploy tool with 'rollback'.

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.

Re:Ant is not what I wanted...

[sfmarco]

I think you are looking for a Source Control System.

BTW: Ant can easily call you SCC tasks. From CVS but also from Microsoft $ourceSafe

Re:Ant is not what I wanted...

[MSBob]

Nope. That doesn't solve everything. There are complex build scenarios where I might say, deploy things in two different remote locations but if one of the ftp sessions fails I want to revert the change in both places. It's more than simple version control of files. It may apply to failed unit tests, failed compiles, failed ftp transfers, missing access rigths and a whole host of things that could go wrong during a complex deployment scenario.

Re:Ant is not what I wanted...

[steve_l]

DTD: create one with , but it has problems because ant is so dynamic. There are discussions about having an XML descriptor for each task so that we could really get it right. You still have to deal with the problem that you could use a task in the same file you compile it.

An ant debugger. Maybe, as part of better GUI tools. Maybe we should add a debug interface to the engine and let people (you?) code one. I usually use tests and checks to verify that jars I'm using exist, to list properties, and the infamous -verbose and -debug switches.

Your rollback need shows a limitation of ant: it isnt an installer, not a real one. We use it a lot for server side deployment; in that context my buil file backs off the old war/ear for emergency restoration later. Because the big problems I have is not that the deploy code doesnt work, but what I deployed is broken...

-Steve Loughran, co-author of Java Development with Ant.

Amazon has it for 30% off instead of BN's 20%

[BoomerSooner]

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!)

Re:Amazon has it for 30% off instead of BN's 20%

[Nazghal]

While people are busy saving money www.buy.com offers to beat amazon's prices by 10%. I haven't read the fine print on how this works, probaby a rebate..

Make + Autoconf Combo is great

[sisukapalli1]

Autoconf can do detailed dependency checks, e.g. whether the int is 2 bytes or 4 bytes, or if the compiler can handle some things. When building projects with ant, lot of things may be more difficult to handle (e.g., a situation where we may not have a library for XML parsing), we will get a compiler error rather than a dependency check error.

Ant is a part replacement for make, but developing with ant comes no where near autoconf + make combination.

S

Re:Make + Autoconf Combo is great

[Knight2K]

Ant is also capable of checking to see if required libraries are available. The sample JBoss development project includes this capability to check for the existence of the XDoclet task.

For instance, there is this task that ships with Ant:
Available Task

Most of the time in Java you don't have to worry that much about what endianness, etc. that you would normally do with C or C++, so I think in practice Ant does a very capable job.

If one uses BeanShell you can also do some pretty powerful custom tasks, including writing light-weight Java scripts (not a typo :-) to do all kinds of checks if you need to... not to mention that it is relatively simple to write Ant tasks for all kinds of build needs, including creating jars of classes by dependencies, code metric collection, etc.

I know of a development house that generated a pretty sophisticated code work set system using Ant scripts, add-on tasks, and some bean shell scripts.

It also has some options to avoid recompiling all Java files when only some have changed, just like make.

Any Java project I have seen that uses Ant and distributes source has been very easy for me to compile... I would say as easy as autoconf if not easier... and I've found Ant a lot simpler to learn than autoconf.

Having said that, there are some irritating things with Ant (trying to make filesets out of paths is one that springs to mind). And I am certainly a fan of ./configure;make;make install.... but it is all about the right tool for the right job, and Ant is pretty much the de facto answer as far as Java development is concerned.

Re:Make + Autoconf Combo is great

[Dan-DAFC]

Autoconf can do detailed dependency checks, e.g. whether the int is 2 bytes or 4 bytes, or if the compiler can handle some things Ant is primarily for Java development, where these aren't really issues because the target is a virtual machine. Data types are the same size regardless of platform (int is always 4 bytes etc.).

Re:Make + Autoconf Combo is great

[steve_l]

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

a positive example of open source power!

[someguyintoronto]

Ant a positive example of where the true goals of open source have succeeded. By offering a simple framework to extend build tasks, many other open-source development tools have been able to easily plugin to the Ant framework. It is in a word a community success.

On another note, I always find it interesting that a book is published on Ant while it is probably the best documented project underneath the Jakarta umbrella.

Re:a positive example of open source power!

[stevecoh1]

>>Ant a positive example of where the true goals of open source have succeeded.

Right you are!

And I especially like the way they have managed to include not only "Open Source heroes" who read the developer mailing list religiously and know every corner of the project, but also the occasional contributor such as myself, who needed something on one of the "optional tasks" and took the bull by the horns.

Ant rocks, but watch out for chmod +x...

[tcopeland]

....I mean, if you use the Ant zip task to bundle up some files, you'll lose any execute permissions that you had on those files.

So if you do an automated deployment of an app that includes some scripts, you'll need to chmod them again before they'll work.

Other than that, Ant rules.

tom

Re:Ant rocks, but watch out for chmod +x...

[steve_l]

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

Re:Ant rocks, but watch out for chmod +x...

[tcopeland]

Hey Steve -

Right, it's just something to watch out for if you're using the zip task.

I ended up working around it by using the exec task to run the native zip command...

Yours,

tom

Ant is just a tool

[Anonymous Coward]

I found Tomcat book from Wrox more than useful. Definitely Ant is powerful, but I dont need more.

Ant is a neat tool

[Anonymous Coward]

I've found ant to be a fantastic tool. I used to use make files, but I started using ant for quickly testing and then deploying builds on different platforms. It can be used for all types of programs, not just java, so it's great for managing cross platform development in a standard way rather than having different build processes on different platforms.

I dislike Ant

[DeadSea]

It is not as flexible as Make. Sure make has its limitations, but I can hack around all those with a little bash scripting. Compiling Java programs is slow because you have to recompile everything? Well my make files don't do that (see the JAVAFILES=$(wildcard *.java) section).

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.

Re:I dislike Ant

[javatips]

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?)

With Ant, you can also do it, use the task and your done.

You can also write you custom task that will invoke the tool the way you want it.

Re:I dislike Ant

[FatherBusa]

Compiling Java programs is slow because you have to recompile everything? Well my make files don't do that. . .

Uh, and neither does Ant . . .

Re:I dislike Ant

[DeadSea]

Compiling Java programs is slow because you have to recompile everything? Well my make files don't do that. . .

Uh, and neither does Ant . . .

That is true. Most people that I have heard spouting about Ant list it as a big feature. They don't seem to realize that Make has the feature as well.

It's do-able

[JediTrainer]

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.

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 .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.

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.

Re:It's do-able

[MSBob]

You can sort of do it by relying on certains side effects but it's still far from a built-in 'rollback' support where your scripting engine can undo all its former actions on a specified condition.

You think "the dreaded tab problem" is bad?

[Anonymous Coward]

wait until you work with XML.

Not only is the dreaded "tag" problem much worse, but you have the dreaded problem, the terrifying missing / problem , and the abominal " your attributes andand escape your entities problems.

most text editors can effectively combat the tab problem these days, but hand edited xml files (especially when they get to be over a thousand lines long) are a nightmare.

Speaking of conditional complilation.. JavaMake!

[ahrenritter]

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.

This book is excellent so far

[mcroydon]

I'm about halfway though the book, and so far I think it is excellent. I've been reading it bit by bit over school and other projects. It's extremely readable, seems more informative than a 200-300 page O'Reilly book (which are great for intros, but this goes into a little more detail), and includes good coverage of JUnit testing and how it is integrated into ant.

I had a chance to meet Steve Loughran at Web Services DevCon East, and he's awesome. His website, including a great paper called When Web Services go Bad. He also has a SOAP development blog.

Re:This book is excellent so far

[steve_l]

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.

Re:This book is excellent so far

[mcroydon]

It's a small world. Slashdotsphere, Blogsphere and real life collide.

I was the quiet geek sitting to your left at the resturant the second night of the conference.

Re:This book is excellent so far

[steve_l]

ok, now I remember you vaguely. Glad you like the book, and it was a most excellent conference, was it not?

Re:This book is excellent so far

[mcroydon]

Yes, the conference rocked. Best bang for the buck, and some of the best presentations I have ever seen.

There already is a .NET equivalent of Ant...

[shodson]

It's an open-source project called NAnt

Hyrid system worked best for me

[rocket_rex]

I completely rewrote my previous company's build system in Ant and Make. I used Make to do all the cross platform macro and definition setup and Ant to compile and jar the classes. The build performance gains were incredible. I would have used all Ant, but it just doesn't have the text manipulation functions that are built in to Make that I needed. Plus, a hybrid system of Ant and Make gives you time to transistion as much as you want to Ant on your own schedule instead of having to take a big bang approach to a new build system. Rocket Your humble buid servant.

Re:Hyrid system worked best for me

[nebhale]

You're completely right. I've done the same thing and it allowed me to separate the software developers from the build process. By separating the definitions from the build engines, I've made it so that developers can't run amok on the build targets. I also saw that same performance gains and gained some more by using the winkin utliity of Rational's clearmake. As well, the developers can concentrate on programming and not on learning a whole new build file syntax.

Who needs tools like Ant and Make

[OmniVector]

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?

Re:Who needs tools like Ant and Make

[nebhale]

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.

Re:Who needs tools like Ant and Make

[Anonymous Coward]

LOL

well just try to create a real build process in that IDE of yours

Re:Who needs tools like Ant and Make

[Adam Fisk]

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.

Re:Who needs tools like Ant and Make

[eduardodude]

Large companies have departments that manage testing, promoting and building applications for production. Mechanisms must exist to do these things that are automatable, repeatable and done from the command line. Why should a change management monkey have to start up an IDE to modify and recreate an EAR for a different environment?

Re:Who needs tools like Ant and Make

[Dom2]

Does that IDE of yours run in my 80x25 console?

Didn't think so. Back to vi.

-Dom

Re:Hmmm i wonder..

[Anonymous Coward]

Unfortunately it's the same class that will make you blink out of existence, so you'll never see it.

Here you go: DTD for Ant

[trikberg]

Ant DTD. The link to the download is about halfway down the page. Took me almost 5 seconds with Google. =)

They used to do this on all items.

[BoomerSooner]

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).

Re:IN SOVIET RUSSIA

[MonsterChicharo]

Why, really? Guess what, in the rest of the world we also develop Ant with Java!

Re:Hmmm i wonder..

[loknor]

So: import java.awt.*; import javax.swing.*; import java.stop.sucking.*; *poof* "We're going to need another loknor!"

Can you sell ant to a make user?

[Simon Brooke]

I've been writing exclusively in Java for seven years now. I've tried ant a couple of times and found it so balky and counterintuitive that I didn't bother persuing it. Yes, my Makefiles only work on Linux, but then I only build things on Linux. If anyone else wants to build my stuff on other platforms that is their problem. They can run them just fine on other platforms - that's the joy of Java.

• What problems does ant solve for me that make doesn't do much easier?
• How can I migrate my (considerable) investment in makefiles to ant and why should I bother?

These are the questions I need someone (or some book) to answer. Will this book answer them?

Re:Can you sell ant to a make user?

[piobair]

As a former make junkie I'm definately sold on Ant if for nothing else than the Junit and Manifest file support it offers.

Junit results can be output in XML and run through and XSL transform, then either e-mailed or posted to a website. I do this hourly (mailing the failures) in a nice readable unit test report.

As for building .jar (and variants). Ant has excellent support for putting custom values into manifests such as cvs tags etc.

You could potentially do this in make, but having pre-built libraries for these things and many others makes creating build environments a part-time job instead of a full-time job.

Re:Can you sell ant to a make user?

[RelentlessWeevilHowl]

Make has problems with compiled inner-class files. The "$" in the file name gets interpreted as starting a Make variable. Yes, it's possible to quote them; it's still a pain in the butt to deal with.

Ant can run Java programs in its own JVM, speeding up compilation.

Ant comes with various support tools that you would have to roll yourself in Make.

If none of these have been an issue for you, then you probably don't need to switch.

Re:Can you sell ant to a make user?

[Anonymous Coward]

To address your second question:
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 ... 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.

Cheers.

Re:Can you sell ant to a make user?

[steve_l]

If the combo of make+unix works for you (as it is the combination, make+DOS is mostly broken), then stick with it. You have more important things to do in your life than tweak build processes, and Ant is no silver bullet. It may be shinier than make, but that is a shine of newness, not necessarily longevity.

But I'm going to argue that Ant brings some things to the table you may want

1. Integrated unit testing. Thats Junit and junit reporting, plus extensions like cactus (they couldnt call it EJBUnit or sun would sue them) and httpunit.
   
2. Deployment: email, ftp, custom tasks for the various app servers out there. Its tasks even smart enough to understand about timestamp dependencies to and from an FTP server, down an http get and other places where makefile is limited.
   
3. Xdoclet. Xdoclet turns javadoc tags into code and xml, for those drudge work interfaces (EJB, JMX) and XML deployment descriptors (taglibs, web.xml, EJB, struts, etc). Xdoclet changes how you code. Try it.
   
4. Integration with the rest of the open source build tree. I get Ant from CVS every am, then get Axis, and my build process rebuilds axis before i rebuild my own web service. Granted. I am a committer on both so sometimes I fix axis more than my own code, but integration to the core open source projects is convenient. Take a look at
   the gump to see the nightly build of everything that uses Ant. The gump also shows that ant does scale up nicely
   

We do look at migrating from make in part of the book, chapter 9 I recall. We talk about migration and encourage co-existence: call ant from make or vice versa, so different sub-projects can use the ones they work with. I dont like mixing ant and make in one project, where a project means a single deliverable artifact (like a jar file). So I take such a level of project, ant-ify it and then have the master file (ant or make) call down to the sub project using ant.

Steve Loughran.

Re:Can you sell ant to a make user?

[stevecoh1]

Besides all the other things that the people above me have said, here's another: As an open-source and relatively young open-source project, and had and still does have some rough edges. However, in the two years I've been using it and in the one year since I've been contributing to it, many parts that sucked now suck less or don't suck at all. As to my contributions, they have been to the StarTeam optional task. StarTeam is a proprietary revision control system. This is another advantage of ant. Yes, I could have used make, or ant as well, to simply exec the rather ugly command line tools provided by StarTeam - but ST also provides a java api that is much friendlier to work with and also lets you do a couple of things the command line tools don't. That is something I wouldn't know how to interface to with make. That said, I don't know if these considerations are worth your considerable investment in learning make, but one can always try. At one time I had a considerable investment in make too.

If you work in a team...

[Dan-DAFC]

Unless everybody in your team is going to be forced to use the same IDE, you need another solution. IDEA is great from what I've seen of it, but in our team of five developers we use five different IDEs/editors with everything tied together with Ant and CVS.

Great book, great XML editor

[kelzer]

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.

Ant is multi-faceted

[redshift-systems]

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).

Repeat after me:

[Anonymous Coward]

Shut the fuck up you pompous ass.
Ant is not worth fixing.
You must edit Ant's XML by hand.
How long have you been a moron?

Re:Repeat after me:

[JohnnyCannuk]

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...

ANT IS TOO DAMN SLOW

[trance9]

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.

Re:ANT IS TOO DAMN SLOW

[steve_l]

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.

Also bought the book

[Real_AzRAel]

..i work with ant some time now, but this book thought me lot i haven't known before!! If you are interested in ANT & Co buy this book and be happy :))