CHA PTE R 1 in Java

Printer Data Matrix ECC200 in Java CHA PTE R 1

With a new release every six months or so, it is likely that a new version will emerge during the lifetime of any significant project. This may seem like a risk, but really is an opportunity: if the current version does not meet all your needs, then filing bug reports or submitting changes may ensure that the next official version of Ant will meet your needs. If the current version of Ant does work fine, then there is no need to upgrade until you feel it is necessary; and there is nothing to stop you from keeping the version used in your project under source code management, to ensure that it will still build many years into the future. One area where the evolution of Ant does create problems is in the documentation, both online and printed. Although the core Ant manual pages are kept up to date, referenced articles and presentations on other sites may be out of date. This book has the same problem. We started writing this just as Ant 1.4.1 came out, yet we targeted the forthcoming version, Ant 1.5. If we had only covered Ant 1.4.1, readers would have missed out on all the improvements that are already in the pipeline. Even the act of writing this book has a side effect on the next version of Ant: rather than explain why things do not always work as expected, sometimes it is easier to fix them. Consequently, much of what we describe does not work on older versions. We have targeted Ant 1.5 and successors with this book, because even if you were using an older version, it costs you nothing but the time to download a new version from jakarta.apache.org. If we had tried to be compatible with older versions of Ant, it would have been much harder to explain and demonstrate many things. Because new versions of Ant come out so regularly, this book will slowly become less accurate. Nothing in the book should actually break with future versions of Ant; the Ant team strives to maintain backwards compatibility with existing builds. But easier ways of doing things will emerge. We strongly recommend that you consult the latest Ant online documentation as well as our book. At some point, Ant 2.0 will come out. This new version of Ant will break many things, probably including builds and plug-in tasks. We do not cover Ant 2.0 at all, as we do not know what it will be, exactly. We do know what the feature requirements are, and that one of them will be an automated means of migrating Ant 1.x builds to Ant 2.0. So do not worry about Ant 2.0 making all your work obsolete. There could even be a means of calling Ant 1.x builds from Ant 2.0, so old build code and new build code can live side by side. Because Ant s change is so public and frequent, it may seem less stable than existing products. However, every night, one person s computer attempts to build the planet s most popular open-source Java projects from their latest source, using the latest version of Ant as the foundation. When that build breaks because of a change in Ant, the owner of that computer, Sam Ruby, lets the Ant development team know. Because of that nightly build (known as Gump2), changes to Ant rarely break other people s projects, which is good news for everyone who relies on Ant as their build tool.

See http://jakarta.apache.org/gump/

Ant plays well on any platform that supports Java, but it also plays well with any software development methodology in use. Regardless of the higher level processes in place, we all, as Java developers, need a tool that facilitates the mundane error-prone tasks involved in building a Java project from source code to end product. Two such popular methodologies are eXtreme Programming and the Rational Unified Process, and there are several other variants of these. How does Ant fit into these methodologies

eXtreme Programming At a business level, eXtreme Programming (XP) is about flattening the cost-of-change curve so that it is no more costly to add a feature later in the development cycle than early on. Viewed from traditional methodologies such as the waterfall methodology, this seems insane. How can change have such little effect The idea is that change is embraced; it is planned for and expected. The software is continually refactored during development to keep it simple, clean, and agile at all times. Change occurs in small incremental steps when using XP, leaving the system ever in a production-ready state. Feedback is rapid, with end-users ideally on site during development to provide immediate answers. Testing is the key to agility Quality is the one inflexible variable of the four variables in a software project: cost, time, quality, and scope. Quality is usually the one to focus on, because anything else just delays problems until they cost more to fix. (Scope is the ideal adjustable parameter, with the others being more or less constrained outside of the development team.) Quality is obtained by testing. Unit tests are developed before production code is even written. Continuous testing and integration are crucial to obtaining agility in adaptation to change. Keeping code simple and clean is tough as it evolves and as cruft forms, but having test suites in place gives developers the courage to undertake massive refactorings to simplify things once again. Run the tests successfully, make some code changes, and run the tests again. If the tests break, you know precisely what just changed to cause the breakage. Ant and XP Ant fits beautifully into an XP process! Automation is mandatory in XP processes. Ant is all about automating build processes, including testing. Advanced uses for Ant could include a continuous integration process, in which a server continually checks out the source and builds and tests the system. Continuous integration is easily realized using an Ant container tool such as CruiseControl or AntHill. We will cover how to do this in chapter 16.