Follow Slashdot blog updates by subscribing to our blog RSS feed

 


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

Java Development with Ant 171

Posted by timothy from the they're-everywhere dept.
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.
This discussion has been archived. No new comments can be posted.

Java Development with Ant More

Java Development with Ant

Comments Filter:

  • Use campusi.com (Score:1, Interesting)

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

  • Well (Score:5, Funny)

    by acehole ( 174372 ) on Thursday November 14, 2002 @12:05PM (#4668717) Homepage
    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.

  • Ant is... (Score:5, Informative)

    by dubious9 ( 580994 ) on Thursday November 14, 2002 @12:13PM (#4668795) Journal
    ... 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 [apache.org] and see what is all about.

    Also, it has become somewhat of the defacto standard in open source Java development.

    • Re:Ant is... (Score:4, Insightful)

      by GusherJizmac ( 80976 ) on Thursday November 14, 2002 @12:15PM (#4668809) Homepage
      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`

      • 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... (Score:3, Informative)

        by yog ( 19073 )
        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... (Score:3, Informative)

          by steve_l ( 109732 )
          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
      • 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.

    • 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).
    • 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 [netbeans.org] 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)

  • Ant sucks (Score:3, Interesting)

    by Trinition ( 114758 ) on Thursday November 14, 2002 @12:16PM (#4668818) Homepage
    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 (Score:3, Insightful)

      by revscat ( 35618 )

      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?

      • 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'.
        • Apples and oranges. He said that it is good for "90% of the build process", not that it fails 1 out of 10 times.
          • 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 (Score:3, Insightful)

      by gss ( 86275 )
      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.

  • ... 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 (Score:5, Informative)

      by Richard_Davies ( 250599 ) on Thursday November 14, 2002 @12:55PM (#4669135)
      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 (Score:5, Insightful)

        by yog ( 19073 ) on Thursday November 14, 2002 @01:04PM (#4669233) Homepage Journal
        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.
        • 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 (Score:5, Insightful)

      by PosterChild ( 49670 ) on Thursday November 14, 2002 @01:01PM (#4669204)
      >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.
      • 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.

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

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

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

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

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

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

  • The book is divided (Score:2, Insightful)

    by automag_6 ( 540022 )
    >>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.
    • presumably after reading through the beginner section, you will no longer be a beginner, and are ready for the interediate section.
    • 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.

  • Ant is not what I wanted... (Score:4, Interesting)

    by MSBob ( 307239 ) on Thursday November 14, 2002 @12:42PM (#4669033)
    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.

    • It's do-able (Score:4, Insightful)

      by JediTrainer ( 314273 ) on Thursday November 14, 2002 @01:13PM (#4669342)
      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.
      • 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.
    • 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
      • 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.
    • Ant DTD [www.sdv.fr]. The link to the download is about halfway down the page. Took me almost 5 seconds with Google. =)
    • 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.
  • 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.
  • ....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
    • 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

  • I dislike Ant (Score:3, Informative)

    by DeadSea ( 69598 ) on Thursday November 14, 2002 @01:04PM (#4669236) Homepage Journal
    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 [jcvs.org] (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.

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

  • 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 [experimentalstuff.com] It can be easily integrated with Ant [experimentalstuff.com] 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.
  • 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 [sellsbrothers.com], and he's awesome. His website [iseran.com], including a great paper called When Web Services go Bad [iseran.com]. He also has a SOAP development blog [iseran.com].

  • It's an open-source project called NAnt [sourceforge.net]
  • 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.

  • Who needs tools like Ant and Make (Score:3, Interesting)

    by OmniVector ( 569062 ) <see my homepage> on Thursday November 14, 2002 @02:51PM (#4670407) Homepage
    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?
    • 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 (Score:5, Informative)

      by Adam Fisk ( 536262 ) on Thursday November 14, 2002 @05:57PM (#4672367)
      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.

  • Can you sell ant to a make user? (Score:3, Interesting)

    by Simon Brooke ( 45012 ) <stillyet@googlemail.com> on Thursday November 14, 2002 @03:28PM (#4670857) Homepage Journal
    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?

    • 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 [sf.net]. 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 [apache.org] 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.

  • Great book, great XML editor (Score:3, Interesting)

    by kelzer ( 83087 ) on Thursday November 14, 2002 @05:03PM (#4671883) Homepage

    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 [apache.org], which can automatically create a web service from any Java class source file. It also teaches you how to use JUnit [junit.org] 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 [sourceforge.net]. It has built in support for creating Ant build.xml files, as well as Cocoon [apache.org] sitemap files, XML schemas, etc. IMHO, it's got the best XML editing GUI I've found.

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

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

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close