| | Ant is a platform-independent scripting tool that lets you construct your build scripts in much the same fashion as the "make" tool in C or C++. You can use a large number of built-in tasks in Ant without any customization. Some of the most important tasks are shown in the following table but explained in more detail in the example that follows. | Since Java is a platform-independent language, it makes sense to avoid tying your build script or process to any particular OS, as far as possible. That would avoid hardships if the development platform were to change later. | In this article, I introduce Gant, a new breed of build tool built on the familiar foundation of Ant. Rather than using XML, Gant lets you describe your build process using Groovy scripts. Using a Java-runtime-based programming language to describe automated build tasks gives you many of the same advantages Martin Fowler lists for Rake, a build language based on Ruby. Gant essentially lets you access the full power of Groovy (and Java) any time you need it, without having to drop out of your build description language to do interesting things. For instance, you can easily use control structures to express build logic, and you can even weave Java code into your build script. Using Ant (and thus XML) means switching over to custom Ant tasks or third-party libraries to perform many of the tasks that make your build worthwhile. | Like it or not, service-oriented architecture (SOA) is a hot topic, and SOAP-based Web services have emerged as the most common implementation of SOA. But, as James Governor put it, "SOA reality brings SOA problems." You can mitigate these problems by creating useful Web service clients, and also by thoroughly testing your Web services on both the server side and the client side. WSDL files play a central role in both of these activities, so in this article Klaus P. Berg presents an extensible toolset that facilitates client-side WSDL processing using Gant and Groovy. | In this article, I introduce some techniques to save you time by preventing redundant rebuilds of up-to-date sources and doing faster builds on outdated sources. | I needed to add a new task to an Ant-driven build and I implemented that task using Spring, a lightweight IoC (Inversion of Control) framework. I encountered virtually no issues since, because an IoC container is noninvasive, it is relatively easy to create a wrapper or just use the objects that implement the task. I then began to wonder if Ant could directly use Spring-configured objects, thus reusing the dependency graph and configuration already specified and tested. Why duplicate and introduce side effects or other problems? If IoC containers really do provide a benefit, a more direct use is warranted. | In this companion to "Client-side WSDL processing with Groovy and Gant," Klaus P. Berg shows you how to get his Groovy and Gant Toolset up and running on Windows XP or Windows Server 2003. While not shown, similar steps are needed to install the toolset for Linux or Mac OS X environments. The screenshot below shows what you will see after following the 10-step installation procedure: | | Ant has been widely celebrated as the future of build processing. In fact, it represents a great improvement over previous make tools: it is extendible, multiplatform, and standard-based. Some Ant characteristics particularly make it the tool of choice: | Antmod's build management is a set of Antmod plug-ins, with each plug-in being a set of Ant build files. Antmod's release management allows you to manage your projects and releases using XML release descriptor files. And Antmod's repository management enables consistent tagging and branching of one or more Concurrent Versions System and Subversion repositories, while enabling easy-to-use versioning of your CVS or Subversion modules. This functionality is especially handy for Subversion users. | When I start any new project, I begin by creating the Ant buildfile. Ant defines the build process and is used by every programmer on the team throughout the day. All of the tips in this article assume the Ant buildfile is an important artifact that must be written with care, maintained in version control, and refactored periodically. So here now are my top 15 Ant best practices. | Finally, there's the most convenient way of using antlibs. If the following conditions are met, Ant will automatically load all definitions of tasks and types declared in the antlib: | Editor's Note: In Part 1 of this two-part excerpt from Ant: The Definitive Guide, 2nd Edition, Steve Holzner covered the tasks designed for packaging web applications, including war, cab, ear, and jspc. This week he covers the tasks for deploying web apps with get, serverdeploy, and scp. | A nice feature of Ant is that it is designed to allow you to add your own tasks and use them in an build. This article shows you the basics of writing an Ant task and how to get a task to work. | What problems can users expect? First, things can already go wrong during the installation process if the user doesn't follow the installation instructions accurately. Even if the installation succeeds, problems can appear later. Changes in configuration (like the JAVA_HOME environment variable) or changes in the directory structure can indeed break things. In this article, we will develop an Ant script to run diagnostic tests for a Java application. We will look at a list of possible problems and how to deal with them. For our approach to work, Ant has to be installed on the user's machine. This may mean that your installer will have to provide Ant. | Developing for the Web is bread and butter for Ant developers. There is a wide spectrum of tasks at your disposal: Chapter 4 introduced packaging and deploying applications--including Web applications--with the move, copy, ftp, telnet, sshexec, and mail tasks, but Ant offers more. This chapter covers the tasks specifically designed for packaging Web applications, such as war, cab, ear, and jspc, and for deploying them, such as get, serverdeploy, and scp. I'll cover the custom Ant tasks targeted to specific servers such as deploy, reload, and undeploy. And there's more to come: Chapter 9 covers the many optional Enterprise JavaBeans (EJB) tasks Ant supports. | There's a first step that every single Java project has to go through: setting up a build system. And often before that, choosing a build system. There hasn't been much improvement in the Java world in this area for quite a while; Ant 1.1 was released in July 2000 and Maven was created in 2004. | Like many other people, I've had a love-hate relationship with ANT for sometime now. On the plus side, ANT did away with a whole lotta nastiness that was associated with Make files. The tabs, the colons, the incompatibilities across operating systems, the embedded shell script hacks - all that is gone now. But unfortunately, ANT didn't exactly usher in a golden age of build systems. It's got its own quirks and flaws and design oddities that we've had to live with for some time - the endless unreadable XML, the lack of scripting capabilities (sorry, an ANT task written in Java isn't a script :-), and of course the lack of modular constructs. On the latter, the few anemic nods to modularity have basically sucked, and has lead over and over again to people creating many big build.xml files that are mostly identical, and with little chance for creating corporate/departmental/project build standards beyond offering a reference build.xml file - and instructing developers how to do cut and paste on their OS of choice. If you're one of those feature-matrix comparison people, and you put ANT and Make (or some other build tool of choice) next to each other, I'd say for most people ANT would win out. ANT just has more plusses on its side than Make does. But there's more to life than soulless feature matrixes and comparisons based only on quantity (ha ha, I have 15 more features than you - I win!). Quality plays a part, and so does what I call "must-haves". Any application in any domain must have the minimum feature set of "must-haves" to be considered seriously in the domain, and build tools are no exception. The problem historically with ANT is that while it's got 20 thousand bazillion features, it's oddly neglected some core must-haves that have crippled it since its inception. The biggie for me has always been ANT's complete ignorance on the subject of modular build systems. On the various projects I've worked on over the years, invariably one of the tasks that gets tackled early on is the subject of the build system. Specifically - what's our build structure look like, how do we handle dev vs. QA vs. production builds, and above all how do we standardize the build environment? Stories of how this has been done over the years, and the various levels of success ranging from elegant and slick build system up to massive behemoths that ultimately collapsed in on themselves from their own weight, are beyond the scope of this entry, but the fundamental point remains: how do we make builds consistent, and make it easy for new projects to spin up a standard build easily and in a manner that leverages what's already been done in the past? On that score, ANT has provided two mechanisms: first, the ability to load property files so that ANT "variables" can be set based on the environment is being run in (e.g. you could use different property files for different environments/releases, and with per-developer overrides as well). This gave you a certain amount of configuration variability so you don't have to hard code things in your build files, and it's nice. The second part is the task, which lets you create a build hierarchy - where you have a master builder (no jokes, please) at the top of a hierarchy which goes down through your project tree and trundles through building stuff as it goes along. This is also nice when you need to "build the world" but don't want a world-size build.xml file. But, for reasons I've never understood, ANT just stopped there. We got props files and the task, and the mythical ANT developer stood back and stretched and said "Well, modularities done!". The problem is, while these facilties are nice, they're just not enough if you really want to standardize your build across many projects. Property files are limited in what they let you specify, so you can get configuration variability on a subset of build concepts. And the task only goes top-down. If you're a typical developer 3 levels deep in the hierarchy trying to build your own little widget, this doesn't help you at all. The end result is that despite the facilities ANT gives you, you still end up with a bunch of build.xml files that keep defining the same targets over and over again in the same way. You've still got a culture of cut'n'paste build creations. Because of this, even though ANT is pretty cool in a number of ways, I could never consider it a real build tool. For all the nice features, it had some holes in its design that you could drive the planet Jupiter through (with room for a couple of moons to spare). | In this article, I'll explain exactly what Maven is and which problems it attempts to solve. Then, I'll walk you through automating your own build process using Maven. As Ant currently is the most popular build tool in the Java arena, this article also assumes the reader has a basic understanding of it. | By itself, Rake isn't all that helpful for most Java projects; however, a relatively new project, dubbed Raven, has married the power and expressiveness of Rake with tasks specific for building Java applications. With Raven, Java developers have a truly viable build platform that provides Java-specific features, such as compilation with javac and archiving binaries with jar and war, with the rich expressiveness of the Ruby programming language. | Whether you're a veteran user of Apache Ant in need of a refresher or just starting out with this open source Java?-based build tool, this tutorial provides a wealth of information. With Java developer and Ant enthusiast Matt Chapman from the IBM Java Technology Centre, you'll walk through the steps involved in writing a build file for a simple Java project, and then look at some of Ant's other useful functions, including filesystem operations and pattern matching. You'll finish the course by writing our own Java class that extends Ant's functionality. | Apache Ant is widely used by the Java community to create automated builds. While it's easy to create customizable build files with Ant, there are times when it might be preferable to prompt the user for information during the build. An interactive build process allows novice users to conduct builds without worry and provides a more convenient way for experienced users to make one-time customizations to build properties. This article guides you through the process of extending Ant to support interactive builds. Before reading this article, you should have basic knowledge of Ant, including an understanding of projects, tasks, and properties; for an introduction to Ant, see Malcolm Davis's article "Incremental development with Ant and JUnit" (additional articles are listed in Resources). | Before tackling headless builds, ensure that normal Application Developer builds are successful, and that the Ant build works correctly when invoked from the Application Developer menu. Launching Ant within Application Developer is easy, since Eclipse recognizes build.xml, and when you right-click on it, its context menu has a Run Ant selection. Correct any build problems that appear in the Application Developer console view. The Ant flag -debug helps in troubleshooting Ant-specific problems. As mentioned above, ensure consistency between the Ant and the JRE versions used when running under Application Developer versus running headless. For Ant-specific problems, your best information source is the Apache Ant Web site. | However, in the case of condition types, such hacks aren't necessary. The Ant team has provided the ConditionBase type class, and this class provides working addXXX methods for all the standard Ant tasks as well as a working add(Condition c) method. (The implication here is that they will do their due diligence to keep ConditionBase in sync with the built-in condition types.) Note that ConditionBase also includes these rather helpful methods: | Near the outset of this article, I expressed mild dissatisfaction with the built-in XML logger. I now address my complaints by redesigning the format of the XML data itself. If a task has an exception, it will show up as a child of that task. I dispense with the timing information and I write elements as they happen rather than all-at-once upon completion. (It is better, in my opinion and experience, to have half a log than none at all.) To get on-the-fly elements -- and to simplify the mechanics for this article -- I am actually using direct file I/O rather than use a formal XML API. I also dispense with CDATA sections and instead directly write log messages into text nodes. These decisions, of course, suit my individual needs. Before undertaking a full-blown, XML-based custom Ant logger, you should decide what information you need and how you might want to process it before you decide how to structure the XML data itself. (To quote a professor from my collegiate days: "You can do anything you want, but whatever you do, know what you are doing.") | This material is from Chapter 1, XP and Ant, from the book Extreme Programming with Ant: Building and Deploying Java Applications with JSP, EJB, XSLT, XDoclet, and JUnit (ISBN: 0-672-32562-4) written by Glenn Niemeyer and Jeremy Poteet, published by Sams Publishing. | You provide attribute support by adding the necessary instance variable in your class and providing a corresponding getter/setter method for it. The name of the attribute should match the name of your instance variable so that Ant can most easily determine which getter/setter method is involved as it is processing your custom task. (Chalk it up to some reflection magic.) In other words, if you decide you want an optional "name" attribute in your custom task, you need to create a "name" instance variable and a standard getName/setName method pair. For a build.xml file that looks like this... | In the first part of this series, we established an Ant build file with the following targets: init, clean, compile, test, javadoc, webapp, and war. Now, we will examine the directory structure in which these tasks do their work. | In this installment, we discuss issues of deployment and distribution. We are continuing to use the build.xml file from a real, working Web application -- please download it and follow along. | Automated builds are an essential for highly productive teams. To be effective, teams must learn to recognize psychological barriers and optimize the build to meet them. Whether you are using Maven, Ant, or some other tool to automate builds, the psychology of builds should be taken into account. | JUnit and Ant are indispensable tools for Java development. This article discusses how to use them together more effectively, allowing you more control over which test cases get run. We'll start by showing how to run a specific Test class from Ant, and then move on to selectively running individual test case methods inside a Test. | Because you run the tests so infrequently, they are often fraught with errors. Consequently, you and your team have begun to question the value of unit tests: if they are so important to code quality, why are they such a pain? You all agree there is a fundamental value to unit tests, if only you could run them in a more agile manner. |
|