Professional Java Tools for Extreme Programming: Ant, XDoclet, JUnit, Cactus, and Maven

Overview

What is this book about?

The Extreme Programming (XP) methodology enables you to build and test enterprise systems quickly without sacrificing quality. In the last few years, open source developers have created or significantly improved a host of Java XP tools, from XDoclet, Maven, AntHill, and Eclipse to Ant, JUnit, and Cactus. This practical, code-intensive guide shows you how to put these tools to work — and capitalize on the ...

See more details below
Other sellers (Paperback)
  • All (22) from $1.99   
  • New (8) from $19.19   
  • Used (14) from $1.99   
Sending request ...

Overview

What is this book about?

The Extreme Programming (XP) methodology enables you to build and test enterprise systems quickly without sacrificing quality. In the last few years, open source developers have created or significantly improved a host of Java XP tools, from XDoclet, Maven, AntHill, and Eclipse to Ant, JUnit, and Cactus. This practical, code-intensive guide shows you how to put these tools to work — and capitalize on the benefits of Extreme Programming.

Using an example pet store application, our expert Java developers demonstrate how to harness the latest versions of Ant and XDoclet for automated building and continuous integration. They then explain how to automate the testing process using JUnit, Cactus, and other tools, and to enhance project management and continuous integration through Maven and AntHill. Finally, they show you how to work with XP tools in the new Eclipse IDE.

Complete with real-world advice on how to implement the principles and practices of effective developers, this book delivers everything you need to harness the power of Extreme Programming in your own projects.

What does this book cover?

Here are some of the things you'll find out about in this book:

  • How to automate the building of J2EE apps and components with Ant and XDoclet
  • Techniques for automating Java testing using JUnit
  • Procedures for automating servlet, JSP, and other J2EE testing using Cactus
  • Ways to automate Swing testing with Jemmy, JFCUnit, and Abbot
  • How to manage projects using Maven
  • Techniques for automating continuous integration with AntHill and Cruise Control
  • How to harness plugins for JUnit, Cactus, and Ant in the Eclipse IDE
  • Ways to implement Extreme Programming best practices

Who is this book for?

This book is for enterprise Java developers who have a general familiarity with the XP methodology and want to put leading Java XP tools to work in the development process.

Read More Show Less

Editorial Reviews

From the Publisher
“...Practical account of using standard tools…”  (Visual Systems Journal, March 2005)
Read More Show Less

Product Details

  • ISBN-13: 9780764556173
  • Publisher: Wiley
  • Publication date: 4/23/2004
  • Edition number: 1
  • Pages: 768
  • Product dimensions: 9.25 (w) x 7.50 (h) x 1.50 (d)

Meet the Author

Richard Hightower is Chief Mentor/Consultant for ArcMind, a full-service software development company. Rick is a software engineer by training who specializes in software development tools and processes, and developing enterprise applications using J2EE, XML, UML, JDBC, SQL, and open source technologies. Formerly he was the Senior Software Engineer for Java Architecture at Intel’s Enterprise Architecture Lab. Rick is the co-author of Professional Jakarta Struts, and he contributed two chapters to the book Mastering Tomcat.
Rick has spoken at a variety of industry conferences and events, including JavaOne, TheServerSide.com Software Symposium JDJEdge, WebServicesEdge, and the Complete Programmer Network software symposiums.

Warner Onstine is a founder and CTO of Interface Guru, a leading Web Usability firm where he consults on back-end technology issues with specific emphasis on how technology and usability work together to present the user with an easy-to-use interface. Warner also runs his own custom development shop, Sandcast Software, which focuses on community and team-oriented software.
Warner got his first computer, a TI-99 4/A, when he was 9 and almost immediately attempted to program a game in Basic on it, which did not work. He stubbornly refuses to get rid of that machine though, along with his trusty NeXT Turbo MonoStation, upon which he got his first taste of Objective-C. This eventually led to Java, skipping right over C++.
His strong community background soon led him to open source, where he has had the chance to meet and interact with several incredible individuals from Jakarta and other open source communities. This also has helped him to keep an open eye on the trends that will soon shape the new landscape—one of his specialties.
Another skill he has is in assisting companies with making the right choices at the right time, utilizing XP, in-depth knowledge of their subject area, and the currently available tools germane to their problem. Warner is also a co-founder and President of the Tucson Java Users Group, which he helped form in 2001, which keeps him rather busy at times. Previously, Warner worked at eBlox, Inc. (a Web development company), Intalio, Inc. (a bay-area Business Process Management Server company), and the University of Arizona Main Library on the Digital Library Team.

Paul Visan is an expert J2EE developer. He serves as a Principal Software Engineer for eBlox, Inc, where he finds that open source tools are invaluable to his work. Paul is a proud Romanian native, now living in the heart of Tucson Arizona. He is a regular contributor to IBM’s developerWorks, for which he has written a series of tutorials on Java Web Services. Paul would like to thank Andrew Barton, Nicholas Lesiecki, Tim Ryan, and Victoria McSherry for helping with this book.

Damon Payne currently works as the Microsoft Business Group manager for Centare Group, Ltd. in Milwaukee, WI. Damon is very passionate about open source technology in the Java and Microsoft .NET worlds. His other professional interests include Mobile development, data persistence patterns, and product development. When not programming or speaking Damon enjoys raising his wonderful daughter, Brooke, home theater, and music.

Joseph D. Gradecki is a software engineer at Comprehensive Software Solutions, where he works on their SABIL product, a enterprise-level securities processing system. He has built numerous dynamic, enterprise applications using Java, AspectJ, servlets, JSPs, Resin, MySQL, BroadVision, XML, and more. He is the author of Mastering JXTA and the coauthor of MySQL and Java Developer's Guide (with Mark Matthews and Jim Cole). Joeholds Bachelors and Masters degrees in Computer Science and is currently pursuing a Ph.D.

Kate Rhodes is a self-taught programmer, serial entrepreneur, and occasional musician with a Japanese nickname and an unstoppable urge to learn new things, solve new problems, and write open source apps. She’s got too many pets, too many projects, and too little time. If she could afford an army of programming minions she’d have one.
She’s ranked better than most and worse than some. She’s worked in impressive places you’ve possibly heard of and unimpressive places you’ve never heard of. She’s done some stuff she’s very proud of and some she isn’t. And so long as life keeps offering up interesting new challenges for her to learn from, she’s happy. If you’re overcome with curiosity you can always see what Kate and her wife are up to at www.masukomi.org.

Robert Watkins is a Brisbane, Australia-based software developer of nine years’ experience. He’s been called a programmer, a software engineer, an architect, and a few other things (many unprintable), but mostly ignores the titles and does what he has to do. These days he is mostly working in J2EE and related technologies, and is a passionate advocate of agile development techniques. When not working, he spends most of his time with his wife and twin children, and when he gets a chance, he takes time out to read Terry Pratchett novels. Robert is also one of the developers on the CruiseControl project.

Erik Meade is an employee of Wells Fargo, who attended XPImmersionTwo, interviewed at XPImmersionThree, coached at XPImmersionFour, and hung out on the evenings of XPImmersionFive. He is the edior of junit.org and an evangelist of JUnit, Ant, CruiseControl, HttpUnit, Tomcat, and open source in general. He is also a contributor to JUnitPerf.

Read More Show Less

Table of Contents

Introduction.

Part I: Key Concepts.

Chapter 1: Introduction to Extreme Programming.

Chapter 2: J2EE Deployment Concepts.

Chapter 3: Storing and Managing Code with CVS.

Part II: Automated Building and Continuous Integration.

Chapter 4: Ant Primer.

Chapter 5: Building Java Applications with Ant.

Chapter 6: Building J2EE Applications with Ant.

Chapter 7: XDoclet Primer.

Chapter 8: Building J2EE Web Components with Ant and XDoclet.

Chapter 9: Building EJBs with Ant and XDoclet.

Chapter 10: Building Struts Apps with Ant and XDoclet.

Chapter 11: Creating Custom Ant Tasks.

Chapter 12: Creating XDoclet Custom Tags and Templates.

Part III: Automated Java Testing.

Chapter 13: Unit Testing with JUnit.

Chapter 14: Load Testing with JunitPerf.

Chapter 15: Defect Tracking with Bugzilla.

Part IV: Automated J2EE Testing.

Chapter 16: Functional Testing with HttpUnit.

Chapter 17: Performance Testing with Jmeter.

Chapter 18: Cactus Primer.

Chapter 19: Testing Servlets and Filters with Cactus.

Chapter 20: JspTestCases and Testing Custom Tags with Cactus.

Chapter 21: Testing EJBs with Cactus.

Chapter 22: Code Coverage with jcoverage.

Part V: Automated Swing Testing.

Chapter 23: Swing Testing with Jemmy.

Chapter 24: Swing Testing with jfcUnit.

Chapter 25: Swing Testing with Abbot.

Part VI: Continuous Integration, Project Management, and IDEs.

Chapter 26: Managing Projects with Maven.

Chapter 27: Automating Continuous Integration with CruiseControl.

Chapter 28: Automating Continuous Integration with AntHill.

Part VII: API Tag Reference.

Chapter 29: Ant Tag Reference.

Chapter 30: Ant API Reference.

Chapter 31: JUnit API Reference.

Chapter 32: Cactus API Reference.

Chapter 33: HttpUnit API Reference.

Chapter 34: JUnitPerf API Reference.

Part VIII: Appendix.

Appendix A: Example Applications Used in This Book.

Index.

Read More Show Less

First Chapter

Professional Java Tools for Extreme Programming

Ant, XDoclet, JUnit, Cactus, and Maven
By Richard Hightower Warner Onstine Paul Visan Damon Payne Joseph D. Gradecki Kate Rhodes Robert Watkins Erik Meade

John Wiley & Sons

ISBN: 0-7645-5617-7


Chapter One

Introduction to Extreme Programming

This chapter is a brief overview of the Extreme Programming (XP) methodology as it applies to developing enterprise-level software in Java. The tools described elsewhere in this book will help you realize many of the goals of XP, but you do not have to adopt the entire XP methodology to get value out of this book and chapter. Automated testing, for example, can help you refactor code regardless of whether you are doing pair programming. Continuous integration can help you detect and fix problems early in the lifecycle of the system regardless of whether your customer is on site. However, because this book discusses XP throughout, it is useful to have a short overview of the entire methodology. If you are already familiar with XP, you may want to turn directly to Chapter 2, "J2EE Deployment Concepts."

XP Overview

XP is a lightweight methodology that focuses on coding as the main task. With XP, the code-centric activities are in every stage of the software development lifecycle. Some practitioners of more traditional methodologies (most seem to be CASE tool vendors) have criticized XP, claiming that it involves reckless coding and is not a real process.

On the contrary, XP is an extremely disciplined methodology that centers on constant code review; frequent testing; customer involvement and rapid feedback; incessant refactoring and refining the architecture; continuous integration to discover problems early in the development process; ongoing design and redesign; and constant planning. The following sections of this chapter discuss the core values, principles, and practices of XP.

Four Values of XP

Kent Beck, originator of the XP methodology, defined four key values of XP:

Communication

Simplicity

Feedback

Courage

Communication is facilitated through pair programming, task estimation, iteration planning, and more. The goal of communication is to provide a place where people can freely discuss the project without fear of reprisal.

Simplicity may seem counterintuitive because it is common in our industry to overly complicate our development projects. The aim of a project is not for the alpha developer to show his technical prowess, but to deliver value to the customer. Don't over-design algorithms. Don't create an artificial intelligence system when all you need is a few if statements. Don't use EJB or XSLT just because doing so will look nice on your résumé. Choose the simplest design, technology, algorithms, and techniques that will satisfy the customer's needs for the current iteration of the project.

Feedback is crucial and is obtained through code testing, customers' stories, small iterations/frequent deliveries, pair programming/constant code reviews, and other methods. For example, if you are unitlevel testing all the code you write several times a day, you are constantly getting feedback about the quality and production worthiness of the system. If something is wrong, you will know right away, instead of being unpleasantly surprised the night before product launch.

Courage is all about being brave enough to do what is right. Have you ever worked on a project where people were afraid to throw away code? I have. The code was horrible and convoluted, and it systematically broke every style, rule, and convention. Yet management and quite a few developers were afraid to throw away the code because they weren't sure how discarding it would affect the system. If you follow the tenets of XP, you will not have this problem. Unit regression testing builds an intense sense of courage. When you know the changes you make will not break the system in some unforeseen way, then you have the confidence to refactor and re-architect code. Testing is key to courage.

If, after several iteration of a project, you find a cleaner, less expensive, more performant way of developing a system, you will have the courage to implement it. I have, and it is a blast.

Five Principles of XP

Building on the four values of XP, Beck created five overriding principles for XP development:

Provide rapid feedback

Assume simplicity

Make incremental changes

Embrace change

Do quality work

The idea behind rapid feedback is that the faster you get feedback, the more quickly you can respond to it and the more it guides the process of designing, coding, and delivering the system. This feedback does not simply focus on automated testing and continuous integration to spot problems early, but also encompasses short iterations that are given to the customer to ensure that the system they need is ultimately delivered. This constant steering and learning helps keep the cost of change low and enables the developer to assume simplicity.

Assuming simplicity means treating every problem as a simple problem until proven otherwise. This approach works well, because most problems are easy to solve. However, it is counterintuitive to common thought on reuse and software design. Assuming simplicity does not mean skipping the design step, nor does it mean simply slinging code at a problem. Assuming simplicity requires that you design only for the current iteration. Because you are getting rapid feedback from the customer as requirements change, you will not waste time redoing code that was designed to be thermonuclear-resistant when all that was needed was a little waterproofing. The fact is, the customer's requirements always change during the development process, so why not embrace the alterations? My feeling has always been that the true test of every design is when the rubber meets the road-that is, when you are coding.

Incremental change fits nicely with simplicity. Don't over-design a system. It is always better to do a little at a time. Let's say you have decided to redo a Web application that currently uses XSLT (a technology for transforming XML data) so that it instead uses JavaServer Pages (JSP; a technology that is commonly used to create dynamically generate Web pages), to improve performance of the system.

Instead of attacking the whole system, why not just incrementally change the pages that get the most traffic first, thus getting the biggest bang for the buck while minimizing risk? As more and more of the system is done, you may decide to leave some parts using XSLT; or, after partially finishing the JSP version, you may decide to do something else. By testing and deploying on a small scale, you can make decisions based on live feedback that you otherwise could not make. This is the rubber hitting the road. (By the way, I am making no design judgments on XSL or JSP. This is just an example for illustration.)

It has been said that a picture is worth a thousand words. Well, a working model deployed to production is worth a thousand pictures. This is the synergy among rapid feedback, incremental change, and keeping it simple. XP goes further than incrementally changing the system. XP relishes change; it embraces change.

Have you ever heard a developer or a project manager declare that once the requirements were set, the customer should not change them? I have. This requirement seemed logical, but wait-isn't the system being built for the customer?

Conversely, XP developers relish and embrace change. Change is expected, because you are delivering business value incrementally to the customer. The customer has plenty of time to give rapid feedback and request needed changes. This process improves the quality of the system by ensuring that the system being built is the one the customer really needs. Customer are happy because they can steer the next revision before the project gets too far off track from their current business needs.

One of the things that drove me to XP was the principle of quality work. I feel better about myself when I deliver quality work. Early in my career, my team was required to certify that every line of code was tested: 100 percent "go code" and 85 percent exception-handling code. At first I was shocked.

I soon realized that certifying the testing of every line of code caused us to write some extremely clean code. No one had the same three lines of code in three different places, because if they did, they would have to certify nine lines of code instead of three. This discipline led to less code to maintain and made it easier to make changes because we made the change in only one place.

From that point on, I loved testing. I liked knowing that the code I wrote worked and that I had a test to prove it. This attitude is extremely important, because we are constantly bombarded with new technology and things to learn. As I said, quality work drove me to XP. Previously I wrote my own tests using JPython, a scripting language for the JVM, which I still use for prototyping. Then, I heard about JUnit, and from JUnit I learned about XP.

Of course, the quality work principle applies to more than making you happy. You would much rather write quality code and deliver a quality solution to the customer than write sloppy code and deliver a shoddy solution that does not meet the customer's need. Customers would much rather receive quality code than something that just does not work. It has been said that customers will sometimes forget that software was delivered late, but they will never forget poor quality.

When I was initially learning about XP, it seemed to be about 90 percent common sense, 8 percent "Aha!", and 2 percent revolution. So far, we have been covering the common sense and "Aha!" The next section covers these as well as the revolution.

Twelve Practices of XP

In his landmark book on XP, Beck iterated four basic practices: coding, testing, listening, and designing. These practices are expressed further in 12 major areas of practice, as follows:

Planning game

Small releases

Simple design

Testing

Continuous integration

Refactoring

Pair programming

Collective ownership

40-hour week

On-site customer

Metaphor

Coding standard

Planning Game

The purpose of the planning game is to determine the scope of the current iteration. This step is centered on determining the tasks that are most important to the customer and accomplishing these tasks first. The planning game encompasses the customer's determining the scope of the project, priority of features, composition of the various releases, and delivery dates. The developers assist the customer with technical feedback by estimating task duration, considering consequences and risks, organizing the team, and performing technical risk management by working on the riskiest parts of the project first. The developers and the customers act as a team.

Time is recorded against stories to further refine your estimates of future stories, making project estimation more accurate as time goes on. Customer stories are recorded on index cards. These stories explain the features of the system. The developers work with the customer to decided which stories will be implemented for that iteration.

Small Releases

The philosophy behind the small releases practice is to provide the most business value with the least amount of coding effort. The features have to be somewhat atomic. A feature must implement enough functionality for it to have business value. This step may be counterintuitive, but the idea is to get the project into production as soon as possible. Small releases get feedback from the customer and reduce risk by making sure the software is what the customer wants. In essence, this step uses the Paredo rule: 80 percent of the business value can be completed with 20 percent of the effort. Small releases go hand in hand with the planning game to decide what features will give the biggest bang for the buck, and they also work with the practice of keeping designs simple.

Simple Design

The idea behind simple design is keep the code simple. The simplest design possible does not try to solve future problems by guessing future needs. The simplest design passes the customer's acceptance test for that release of the software.

The simplest design passes all the tests, has no duplicate logic code, and is not convoluted but expresses every developer's purpose. This step goes hand in hand with small releases. If your architecture is not expressed well and is built to anticipate future needs, you will not be able to deliver it as quickly. We are developers, not fortunetellers. We don't have a crystal ball, so the best way to anticipate customers' future needs is to give them a working system and get feedback from them. Most customers don't know exactly what they need until you deliver something tangible that they can react to. Remember, a picture is worth a thousand words, and a working model is worth a thousand pictures.

Testing

The practice of testing is key to XP. How will you know if a feature works if you do not test? How will you know if a feature still works after you refactor, unless you retest? If you admit that you don't know everything, and that the code will change and evolve, then you'll realize the need for a way to test the code when you change it.

The tests should be automated so you can have the confidence and courage to change the code and refactor it without breaking the system! This approach is the opposite of waterfall development.

Code is in a liquid state, so it can be re-architected, refactored, or thrown out and completely redone. Later, the tests can show that the system still works. Testing keeps the code fluid. Because tests typically check the public interface of classes and components, the implementation of the system can change drastically while the automated tests validate that the system still fulfills the contract of the interfaces. A feature does not exist unless a test validates that it functions. Everything that can potentially break must have a test. JUnit and friends will help you automate your testing.

Continuous Integration

Continuous integration is a crucial concept. Why wait until the end of a project to see if all the pieces of the system will work? Every few hours (at least once every day) the system should be fully built and tested, including all the latest changes. By doing this often, you will know what changes broke the system, and you can make adjustments accordingly instead of waiting until modifications pile up and you forget the details of the changes.

In order to facilitate continuous integration, you need to automate the build, distribution, and deploy processes. Doing so can be quite complicated in a J2EE environment.

Continues...


Excerpted from Professional Java Tools for Extreme Programming by Richard Hightower Warner Onstine Paul Visan Damon Payne Joseph D. Gradecki Kate Rhodes Robert Watkins Erik Meade Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)