What do you get when you combine a development methodology for delivering quality software while maintaining a focus on customer satisfaction and an Open Source tool to create build and deployment processes?
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.
Chapter 1: XP and Ant
IN THIS CHAPTER
What Is XP?
The XP Process
Ant and the XP Process
The Scope of This Book
Extreme Programming (XP) is a software development methodology for delivering quality software while maintaining a focus on customer satisfaction. Ant is an open-source tool from the Apache Project for creating build and deployment processes. In this book, you will learn how to implement effective XP processes by using Ant.
What Is XP?
XP development is iterative in nature, and delivers quality software through continuous automated testing and integration. XP development demands simplicity. It means refactoring code that is working to eliminate duplicate or redundant code. It is a focus on the here and now, not on what might be needed a week from now. XP emphasizes constant communication between customer and developers, as well as between developers. In fact, in XP, the customer is part of the team. XP is similar to the just-in-time inventory practices in manufacturing.
Characteristics of XP
XP maintains a focus on customer satisfaction. In XP, the customer is part of the team. That means that the customer has visibility and plays an important role in the overall plan. The customer drives the implementation and releases through writing user stories and participating in the Release Planning meetings. Because software is developed iteratively in XP, a working system is always available with some level of functionality. The customer can always view this working system and assess the state of the project or make changes in the system requirements (user stories). That also means that if the customer pulls the plug on the project, he or she will have something of value to show for the investment made to date.
XP emphasizes teamwork. Developers work in pairs on production code, and they communicate with each other. The customer, or at least a customer representative, is co-located with the development team to answer questions that naturally arise. Everyone on the development team works in different areas of the system, and everyone has ownership of the code. The XP methodology facilitates teamwork and requires trust among the team members.
Using XP adds agility to a project. Because of XP's emphasis on simplicity, quality, and testing, an XP project can more easily adapt to unforeseen circumstances than other heavier-weight methodologies can. In fact, XP expects the unexpected. That's why there is the emphasis on delivering functionality as it's needed, and testing and integrating continuously. Developers are always implementing user stories and delivering functionality as it's needed.
In XP, integration problems are caught early. This is because XP is iterative. Builds, unit testing, integration, and acceptance testing are done continuously. You don't have to go through months of coding followed by a death-march type of integration cycle. Integration is easier because it's happening all of the time. If someone starts to diverge on a meaningless tangent in code development (which is unlikely with pair-programming, and the emphasis on implementing stories), the miscue is caught early, before it has a major impact on schedule.
The Core Values in XP
The heart of XP is its four core values:
Communication is critical to the success of any XP project. That means effective communication between developers, and between the development team and the customer. XP expects that the customer, or a representative of the customer, should be co-located with the development team. This encourages and increases communication and is part of the just-in-time nature of XP. Formal communication occurs between the customer and developer during the Release Planning and Iteration Planning meetings.
Communication occurs between developers during pair-programming. It also occurs between customer and developer when a developer has a question and is able to get a timely response because she can just go talk face-to-face with the customer. Getting timely answers to questions increases the overall quality and success of the project. If a developer has to wait for a document, or a message to be returned, he will probably do one of two things: Either he will guess at the answer or go on to something of lower priority. Neither action is desirable. Although an e-mail dialogue can occur, face-to-face communication is better because it's easier to convey information and to judge how well the recipient understands it.
Simplicity is often harder to achieve than complexity. It requires a commitment to achieve simplicity. In XP, this means that we don't code things that we think we might need at some point down the road. Developers code what is needed to meet the current requirements. As a development team, we strive to maintain a simple design. It also means that we have a constant focus on refactoring to eliminate redundant code. If after a piece of code is developed, a simpler approach becomes apparent, rewrite the code. Because much of the cost of software is in the maintenance, doing this will actually save time and money in the long run. Also, you won't be afraid to change parts of the system or to refactor classes because of the emphasis on continuous testing in XP.
Another aspect of simplicity is in maintaining coding standards. If code is written in a consistent style, it's much easier for anyone to pick up a piece of code and understand it. Maintain standards for naming variables, methods, and classes. Be consistent in the use of capitalization, braces, and indentation. All of this adds to reducing the complexity and the associated cost of building and maintaining software.
Feedback is achieved in XP through frequent and thorough automated testing. Testing includes unit tests and acceptance tests. XP emphasizes the need to write your unit test for a class before you write the class. You then write the class to pass the unit test. By doing this, a team builds up a large suite of unit tests very rapidly. This practice will more than pay for itself as the project progresses, by preventing catastrophic mistakes that are costly to debug and fix. This also helps to maintain the focus on how a class will be used, and guides the developer into creating only what is needed.
Consider the importance of feedback. For example, no one would open a word processor, disconnect the monitor, and then type a document. The constant feedback provided by seeing the results of our actions on the monitor helps to reduce mistakes. It doesn't eliminate them entirely, but it does help prevent us from going too far off on some tangent. The feedback provided in XP by constantly running automated unit tests each time a build occurs will also help to reduce mistakes. Running automated tests frequently will also eliminate much of the pain normally experienced during the integration and testing cycles of most projects, because problems will be detected early.
There's another reason for testing frequently. When a developer is working on an area of code, that is what is foremost in her mind. The best time to test code is right after it's been written, while the developer remembers exactly what she was doing. If testing is postponed until a week or two after the code was written, and a developer has moved on to other areas, testing and bug fixes will be more difficult. There is a certain amount of ramp-up time to remember what was done and why. Using iterative cycles of unit testing and acceptance testing reduces this problem.
If you have never used XP before, using this methodology for the first time might seem a bit daunting. It does require courage to get started. Courage in XP means that the customer is not afraid to tear up a user story card if it doesn't fit, and to rewrite it. As a developer, have the courage to refactor code even though it's working, but is unwieldy. Don't hesitate to throw away unneeded code or to rewrite an algorithm because you now see a simpler way to do it.
Courage also means being willing to ask questions when you don't understand something. Talk to the customer when you need more information about a story. Don't fear the pair-programming aspect of XP when writing production code. This is all part of the courage required to implement XP.
XP developers are highly productive. First, they are implementing user stories that have the most business value, as determined by the customer. They are doing what is important first. They are not spending time on functionality that is of questionable value. In XP, there is less chance that something just implemented will be useless because it was done months in advance, and the requirements changed after it was implemented. Second, XP developers create high-quality code because they are continuously testing and refining their code. Far less time is spent chasing after bugs whose cause is obscure.
The XP Process
In XP, the customer drives the development priorities. The process starts by the customer developing user stories that describe the operation of the system. User stories should be written on index cards, so they can be shuffled around, marked up, or even torn up. A user story might say something like: "When the user finds an item they want to buy, they can add it to their shopping cart, and continue shopping." A user story should be something that a developer can implement in about a week. Of course, the customer has no way of knowing what a week's worth of work is for a developer. So it's the developer's responsibility to ask the user to break up a story into smaller stories if it's too big, or to combine small user stories into an appropriate sized story.
The user stories form the system requirements, and the customer gets to drive the order and priority of implementing those stories. When the developers look at the user stories, some concerns may arise about how to implement a story or the technology that may be used. In such cases where things are fuzzy, and therefore risky, the answer is to write a spike. The spike is intended to be throw-away code, so it doesn't get developed with the same rigor as production code. The intent is to test and perform a proof-of-concept for something specific. This will allow a more accurate estimate of the time required to implement a particular user story. The phase where customers are writing stories and developers are experimenting with spikes is considered the exploration phase of the iteration.
The Phases of an Iteration - Releases are composed of iterations. A release should contain about three iterations, and each iteration should be about one to three weeks in duration. XP divides the activities within releases and iterations into three phases: exploration, commitment, and steering.
The exploration phase is for information gathering. It involves collecting user stories, determining the requirements of the system, and performimg spikes.
In the commitment phase, the developers take the story cards and estimate the difficulty of each task. Here is where stories might be combined or broken up to create work units of the correct size. Then a release or iteration planning meeting is held to plan the work. At this point, the user stories for the upcoming release or iteration are chosen, based on their business value.
The steering phase encompasses the rest of the iteration or release. Steering occurs by gathering project feedback and then taking corrective action based on that feedback. It is a process of continuous course corrections, much like steering a car. Steering is a very important part of the XP process, because it's done continuously. Some traditional forms of project management may go weeks or months without serious corrective action based on feedback. It's easy for projects like this to go astray. In XP, software is tested and integrated many times per day. Continuous steering ensures that the project will stay on track.
The next step is the Release Planning meeting. The customer and the development team meet and go over the user stories that the customer would like to have in the first release. The developers divide into groups and go over the user stories, assigning a difficulty rating, or points to each story. The harder a story is to implement, the more points it gets. This is also the opportunity for developers to ask the customer questions about stories. The developers attempt to estimate how many points they can get done in an iteration, and therefore, how many stories can be implemented in the first iteration. If it's not possible to accomplish everything in the first iteration that the customer wants, it's up to the customer to decide what the priorities are. The customer makes that decision based on the business value of each story, and its estimated difficulty. It's important to plan small, frequent releases, to put new capability into the hands of the customer as quickly and as often as possible.
XP projects typically work in 3- to 4-week cycles called releases. At the end of each release, new functionality in the form of an incremental release is delivered to the customer. Each release is broken up into iterations, which typically are a week long. At the start of each iteration, an Iteration Planning meeting occurs with the development team and the customer. The customer will present each user story in detail, and permit the developers to ask questions about it. The developers in turn will discuss the technical aspects of implementing the story, and put them up on a board. At the end of the meeting, developers sign up for tasks and make commitments for completing those tasks.
After each Iteration Planning meeting, and within each iteration, developers will meet for short design sessions. The tools might include Class-Responsibility-Collaborator (CRC) cards or some Unified Modeling Language (UML) sketches, to get a good idea of what objects are involved, and how they will collaborate.
When the team starts to actually develop code, developers will pair up. The pairs are not permanent arrangements, but arranged to address some particular phase of development. Any given developer might pair with several different people during the course of the work day. When writing code, the pair first writes a unit test that will test the aspect of the class that they're going to implement. Then the class is written, compiled, and tested. Writing the unit tests and classes can be iterative in itself. For example, the unit test may be written to test one method of the class, and then that method is implemented in the class. Then another unit test may be written to test the next method of the same class, and then the second method added. The point is to make incremental changes and test often. Because of the frequency of unit testing, it's imperative that unit testing be automated. In this book, we'll show you how to automate unit tests and make them part of your build process. Also, by having automated unit tests, it will become immediately apparent if a developer makes a code change that breaks something.
At any point when code compiles and passes unit tests, it can be committed to the revision control repository. When this happens, it will be integrated and tested in the overall system. XP relies on a process of continuous integration. This means that the entire system is built on a regular basis, perhaps many times per day. The purpose is to catch problems and inconsistencies as quickly as possible, while they're still easiest to fix. As part of the integration build, tools are used to check for compliance to coding standards, and metrics can be generated. This book also covers the use of open-source third-party tools for accomplishing these tasks, and how to integrate them with Ant as part of the build and deployment process.
Prior to delivering a release to the customer, automated acceptance tests are run. If any of these fail, the bugs are fixed, and the code is rebuilt and tested again. If you plan small releases, functionality can be added incrementally, and quality maintained, while delivering new functionality to the customer on a frequent basis.
The Need for Speed
Working in an iterative methodology like XP means that a development team will be performing builds, unit testing, and integrating many times per day. These tasks need to happen as accurately and rapidly as possible to increase the project velocity. Also, these processes need to be repeatable. That's why these processes must be automated into a repeatable build, testing, and deployment process.
Creating an automated process provides another advantage by enforcing a discipline in the thought process. When creating an automated build process to perform a task, you as a developer are forced to think through all the details with greater stringency than you would if you simply documented a procedure. A written procedure doesn't have to compile or execute, and it's easy to miss a step or make a mistake. Certainly, the written process can be tested by users and debugged. Conversely, an automated procedure is not guaranteed to be bug-free. But even with a well-debugged written procedure, as complexity increases, so does the likelihood of human error when following it.
In short, an automated process means less drudgery for the developer and fewer errors. That translates into increased speed. In the spirit of XP, it's mandatory to automate as much as possible to reduce the developer workload and the likelihood of errors each time a process is carried out. Any task that must be repeated on a frequent basis should be automated.
Sharing the Knowledge
Another advantage that results from automating a process is that the whole team gets to share the benefit of the knowledge of the developer who created the process. It also preserves that knowledge for the team. When you've validated that an automated procedure works correctly, you only have to make it available to other developers to ensure that this procedure will then be run consistently by all users.
This can shield the development team from having to know the details of every product in the development environment. This is accomplished by developing Ant rules that handle the details of certain complex tasks. When the team size gets larger, it's unlikely that everyone will have an in-depth knowledge of every aspect of the system, such as the revision control system, for example. Suppose you're using Concurrent Versions System (CVS). Most developers will probably know how to perform basic operations, such as how to do an update, how to check out a module, and how to commit changes to the revision control system. However, they might not understand the nuances of branching or tagging. Perhaps your deployment process requires the developer to deploy Enterprise Java Beans (EJBs) to an EJB container, such as JBoss. This can be a complex task to get right every time, especially when you're under the pressure of a deadline. But if you develop the right rules in your build and deployment tool, the developers won't need this level of knowledge.
Also, as team size increases, it's likely that not every developer will perform certain operations, such as branching, in the same way, even with a written procedure. This could be because of simple human error or a miscommunication. By creating rules in a tool such as Ant to perform development tasks such as revision control access or EJB deployment, you've abstracted the details of the underlying tool.
If you've created the necessary rules in your build process to perform all the tasks that your development team needs to perform for a function such as revision control, it's possible to change the underlying service while maintaining the same procedures for the development team. This really follows the spirit of good object-oriented (OO) design practices at a developer interface level. It's considered a good practice in OO design to "program to an interface, not an implementation" so that your design is not tied to a particular implementation. By abstracting the details of tasks such as EJB deployment or revision control, your team won't have to learn a new set of procedures if the underlying tool changes.
Ant and the XP Process
Ant is an open-source Java-based build tool that enables users to rapidly develop build and deployment processes by configuring an XML file. It's actually a framework that enables a developer to write an XML file that executes a series of actions, where Ant controls the main thread of execution. Ant is ideally suited for implementing XP. It provides the framework needed to set up automated builds, testing, and integration. Ant is also extensible, so if it doesn't have a required capability, the feature can easily be added. There is also an abundance of third-party tools that integrate easily with Ant. It's also possible to integrate tools that weren't designed for use with Ant (examples will be given throughout this book).
The role that Ant fulfills in build processes is analogous to the role that a tool such as InstallShield plays in installation programs. If you're developing an installer for a Windows-based product, using a product for building installers enables you to rapidly configure a very professional-looking installation. Certainly, you could write your own installer from scratch, but it would be time-consuming, with little value added. In the same manner, you can write your own custom build processes, but the question to ask is, "Am I adding value to the project by writing my own build tool?" Most likely, the answer is no. If the real goal is to reduce workload by creating a reliable, repeatable build process, it makes sense to use an off-the-shelf product.
Ant can be used to create a regular automatic build, such as a nightly build. It's a good practice to have such a process in place to routinely build and test the code that has been checked into the revision control system. Another recommended practice is to set up an account that is not associated with any particular developer and then have the build performed under that account. This detects problems caused by differences in the developer's respective environments, such as differences in environment variables.
Why Choose Ant?
Many choices exist for build and deployment processes besides Ant. What advantages does Ant have over other products? What advantages does Ant have over using nothing at all? Some of the options we'll consider in this chapter are make, various Integrated Development Environments (IDEs), and even custom in-house solutions (or proprietary solutions). We also consider why Ant is better than relying on a written process and performing the steps manually.
A major advantage of Ant over many other build tools is that it's platform- independent. Ant is written in Java. Therefore, it can be run on any operating system that has a Java Virtual Machine implementation, which is pretty much every platform. Additionally, Ant has the same logical behavior across platforms. This eliminates the need for special handling of conditions in your build process based on various operating systems that you must support. For example, if you want to create a directory tree, you specify the structure in your XML file. Ant takes care of the differences between operating systems, such as the use of a backslash in Windows but a forward slash on UNIX-based systems. Ant also has properties that can be referenced (like constants). You don't have to be aware of the operating system (unless you use the <exec> task, which enables you to make an operating-systemspecific call).
Make is probably the most serious direct competitor of Ant. First, we should give make its due respect. Make was a tremendous step forward at its inception, enabling developers to create a file for command execution management that could be used to create a repeatable process. Many developers grew up on make and have successfully used it on numerous projects. Also, some common ground exists between make and Ant. Both (Gnu) make and Ant are free software, so cost is not a barrier for choosing either tool. Both can be used to create a build process and are basically platform-independent.
So, why do we consider Ant to be a superior alternative? The biggest advantages of Ant over make are its use of a standard syntax (XML), its rich feature set, and its extensibility. To the uninitiated, make syntax can be very cryptic, whereas XML is more intuitive and self-documenting. In fact, most developers are either familiar with XML or should become familiar with it in the near future.
As the Ant Web site (ant.apache.org) points out, make also has various quirks, such as the infamous tab problem. Probably every make user has had to debug a makefile problem that was caused by an unfortunate (and invisible) space in front of a tab in the file. A space in front of a tab in a makefile breaks the make process, and it's not always obvious that the problem is a space before the tab. In addition, different varieties of make have slightly different behaviors. Certainly, this problem can be circumvented by standardizing on a particular variety of make, such as Gnu make.
Another reason for selecting Ant is that it uses current technology. Developers like to do work that will enhance their marketable skills. They generally don't like to work with technology that is perceived as outdated or as a dead end. It's easier to attract talented people to a project that uses leading-edge technology.
Finally, Ant is open source. This means that you can become a developer for Ant yourself and contribute to it. This also means that others have developed third-party add-ons for Ant. For more information about external tools and tasks for Ant, check the following URL:
Try doing a search on the Internet for a task that fits your requirements. If Ant doesn't already have a capability that you need, you might do a little research before writing your own; someone might have already solved the problem for you. In addition, you can post questions about Ant at mail lists or discussion forums to seek help from the user community. For more information about this, check the Apache Web site at
In fairness, make is a better choice than Ant in some situations. Ant is definitely Java-centric. In fact, it's written in Java. Although it's not imperative for a user of Ant to know Java, it is helpful. Some of the tasks, such as the commands to invoke the Java compiler (javac) or to create Java documentation (javadoc), simply are oriented toward Java. No built-in commands exist for invoking a C or C++ compiler: These can be added through BSF scripting, by writing an Ant task in Java, or by simply using the <exec> task of Ant to execute a command in the native operating system.
Projects that are being developed in C or C++ might be better candidates for make. If the development team has no experience with Java or with XML and is already very familiar with make, the cost of surmounting the learning curve might be not be worth the expense. Another situation in which make might be appropriate is a project with legacy makefiles. If these work well and can be easily maintained, there might not be a compelling reason to shift to Ant. In fact, unless using make actually causes a problem in terms of usability or maintenance, it doesn't make sense to rewrite a well-tested process. However, if a team has no experience with either make or Ant, we recommend Ant as the build and deployment tool of choice.
Some projects elect not to have any formal automated build process. They rely on a developer manually performing a known set of steps for each iteration of the build cycle. Here are some of the pitfalls of this approach. The process must be well documented and communicated to all members of the team. That's certainly true whether or not an automated process is used. However, when a process is automated, changes can be made behind the scenes that don't affect the interface or the way a developer uses the tool. When that's the case, users are shielded from the details of the implementation. They only need to know if there is a change in the manner in which a procedure is run. Suppose that part of your build and deployment process is to deploy Enterprise JavaBeans into an EJB container. If the build tool has a rule for EJB deployment, developers need only to invoke that rule. Suppose that the team decides to change the EJB container product. It's then possible to change the underlying implementation of the rule for EJB deployment without changing the way in which developers invoke it. In this way, the development team is shielded from the changes in EJB deployment procedures because they're automated.
The level of complexity in a manual process is greater than that of an automated process. Because of the increased complexity, the probability of an error occurring in the execution of the task increases. Someone might miss a step, or changes in the procedure might not be communicated effectively throughout the group. Certainly, no tool can solve a lack of effective communication. But again, as the complexity of any procedure increases, the probability that an error will occur also increases. A problem created by missing even a single step in a procedure (such as forgetting to copy a DLL or a JAR file) is often the nastiest type of problem to track down. When the problem is finally found and corrected, nothing of value has been added to the project. Correcting a bug that results in a code change usually improves the product and definitely adds value. By contrast, time spent tracing a bug caused by a procedural error is time wasted.
An automated process removes some of the mundane work and leaves time for the fun and enjoyable work, such as design work and product enhancement. These are the activities that also help the company's bottom line, which is to produce a useful product. Effort spent performing mundane, repetitive tasks that the computer could perform is a waste of the development team's time and talent.
A complex manual process is not a repeatable process. Even if the same person performs the process each time, there's no guarantee that the results will be the same. Certainly, the quality of the outcome is likely to vary among individuals. By configuring a build process, you can debug the process once and then use it repeatedly.
A manual process is also fatiguing because it adds to the overall workload of project team members. If getting a procedure correct under normal circumstances is difficult, it's even more difficult when the team is under pressure, which is often the case in development projects. The time when people are under the most pressure is the time when they're most likely to make a schedule-killing mistake in a procedure. Repeatedly performing a procedure that could be automated is mentally fatiguing and adds to the likelihood that mistakes and schedule slips will occur. It's part of a vicious cycle.
Another downfall of manual build and deployment processes is that they require each team member to have specialized knowledge of the process. When a team member leaves the project, that knowledge is lost. The time and training required to bring new team members up to speed on the procedures increases with the level of complexity of the procedures. Automating those procedures reduces the learning curve for new team members. This also permits team members to develop areas of expertise instead of requiring everyone to be an expert in everything.
No project is too small to have some level of automated processes in place.
Custom and Proprietary Solutions
Some of the disadvantages of custom and proprietary build processes are really true of any proprietary solutions. Most developers we know really don't like to work on them. In fact, most developers prefer to develop skills that they can take with them to the next assignment. Learning the details of an in-house product that's not used anywhere else is generally not appealing. The consequence is that it could be difficult to attract qualified people to the project if it's seen as a technological dead end. Also, with a proprietary solution, you're virtually guaranteed to have to train new members to the project in your methodology. Ant is becoming a widely used tool, so it's possible to hire someone with a working knowledge of the tool.
It might be argued that custom scripts written in a standard scripting language, such as Perl, shouldn't be considered a custom solution. Certainly, it's true that the language itself is a standard and that it's possible to hire people who are experts in it. But there is a downside to choosing a proprietary solution to your problem. Creating proprietary solutions when off-the-shelf solutions exist is generally a bad idea. When using an off-the-shelf tool, you gain the benefit of numerous hours of development, debugging, and testing by the producers and customers of the tool. On the other hand, a proprietary solution requires your team to pay for all the initial development and debugging. Proprietary solutions also require your team to pay for the ongoing cost of maintenance, which includes fixing bugs and adding new features. With an off-the-shelf solution (especially a free open-source tool), the cost of development is amortized over a much larger customer base, making it more cost-effective. In short, a quality off-the-shelf solution will probably be quicker and cheaper to implement and maintain over the life cycle of the project.
Another advantage of Ant is that the buildfiles are written in XML, which is fairly self-documenting. With scripting, unless the writer used meaningful variable names and comments, the script could be fairly obfuscated and unmaintainable. This isn't necessarily the case all the time; it's just that Ant XML files in general are more likely to be easily maintained than custom scripts. Also, just because you have custom scripts doesn't mean that you have to throw them away to use Ant. Ant has a BSF scripting engine capability that enables you to integrate existing scripts.
Integrated Development Environments (IDEs)
Various IDEs on the market help a user with the development process. Most include the capability to define a project's build requirements to facilitate a well-configured repeatable build process. Many also include a lot of other features, including a symbolic debugger, visual graphic design tools, and testing features. Here are some aspects of relying on an IDE for your build process to consider.
One of the disadvantages of relying on an IDE for your build process is that it might tie you to the platform on which your development work is being done. Many Java IDEs are written in Java and, therefore, are platform-independent. If your IDE isn't platform-independent and you must support multiple platforms, you might find that you are maintaining more than one build process. This can be problematic because it's difficult to keep multiple processes in sync. It's also common to experience problems with infrequently used build processes because of changes in the surrounding environment. Another problem when relying on the IDE's build environment is that if you're forced to change IDEs, you must redevelop your build and deployment process. Depending on the complexity, this could be time-consuming.
Another problem with IDEs is that the environment must be set up for each developer. We have worked on projects with more than a hundred developers using an IDE. Sometimes problems are caused by subtle differences in the configuration of development environments among developers. These problems can be difficult to track down.
IDEs are definitely useful. Fortunately, with Ant and IDEs, it's not an all-or-nothing choice. One of the features of Ant is that it can be integrated into many of the IDEs that are now available. This gives you the benefits of both products. You can use the IDE for code development and debugging tasks, and you can use Ant to achieve a common enterprise-wide build process. In Chapter 9, "Company ReorganizedWorking with a New Subteam," we delve into the techniques of integrating Ant with a popular IDE.
Ant is an open-source build and deployment tool that enables users to rapidly configure platform-independent build processes. Because Ant is written in Java, it's supported on any platform that has a Java Virtual Machine implementation available, which is nearly everything. It uses XML, which is a technology that is familiar to many developers. Because XML is fairly intuitive and self-documenting, Ant processes tend to be fairly readable and easy to maintain. Ant has an extremely rich feature set and can be extended when a unique or proprietary function is required. It has a gentle learning curve, and developers can easily put together a useful XML file with very little Ant experience.
But Ant also is a powerful tool that an advanced developer won't quickly outgrow. Because Ant is open-source, it's possible to obtain extensions to it from third-party sources. Ant also offers the possibility of extension by writing custom Java classes or using scripting languages and Ant's BSF scripting engine. If all else fails, a user can always shell out to the native operating system to perform a specific function. Because of these features, developers will never find themselves painted into a corner.
Ant offers numerous advantages over other possible choices for build environments and tools, such as make or various IDEs. Because many IDE products support Ant, users can leverage the power of the IDE while still using Ant.
Admittedly, in some situations, other solutions might be preferable. For one thing, Ant is Java-centric. Although it's not imperative to know Java to use Ant, it is useful. A situation in which another solution might be preferable arises when a development team already has expertise in another technology and has no experience with Ant, Java, or XML. Another case might be a project with a legacy build system that has been thoroughly debugged and works well. In such a case, it might not be justifiable to scrap the current build system in favor of a new one. However, when starting a new project, especially a Java-based project, or when the current build system is difficult to maintain, we believe that Ant should be the tool of choice.
The Scope of This Book
Throughout this book, we'll follow a group in a fictitious company called Networks Byte Design, which is implementing a project using XP. The primary focus will be on the details of how they implement their processes with Ant. But following the project should also provide other insight into the implementation of XP.
This is a book about how to implement XP processes with Ant. This book does not discuss topics such as how to effectively refactor code. It is intended to be a practical guide about implementing the repeatable build, testing, and deployment processes that XP requires, by using Ant. It does cover topics that have to do with automating processes, including
Automating unit tests
Automating acceptance tests
Generating deployment descriptors in the build process
Creating a continuous build process
Creating distributed build and deployment processes
Maintaining project standards (such as coding standards)
Generating metrics about the code
Use of third-party tools
This book will also show how to extend Ant by writing custom components in Java and by using the BSF scripting capability in Ant. Included are a number of custom components written in Java that you can download from the Sams Web site and apply to your project.
About the Authors
Jeremy Poteet has more than 15 years experience in software development. He has led numerous Java development and XP projects and has incorporated Ant at several customer sites. He has been involved in every aspect of the software development process, with team sizes ranging from 1 to over 100. Jeremy is currently the Chief Technology Officer at Technology Partners, Inc., a consulting company specializing in application development and security, located in Chesterfield, Missouri. He was the winner in the 2002 eWeek OpenLabs OpenHack IV competition, and can be reached at email@example.com.
Glenn Niemeyer is a consultant with Technology Partners Inc., a Mid-west based Consulting Firm. He has a Masters Degree in Electrical Engineering from the University of Missouri, and 15 years of experience in software development. Glenn joined Technology Partners in 1996, and has been a technical team leader and project leader on a number of software development projects. He is also active in the area of Application Security. Glenn can be reached at firstname.lastname@example.org
Source of this material
To access the full Table of Contents for the book
Other Chapters from Sams Publishing:
Web Services and Flows (WSFL)
Overview of JXTA
Introduction to EJBs
Processing Speech with Java
P2P Dynamic Networks