This article will describe some of the development tools that are available from the Java Open Source community and explore how they can help you create high-quality software in a predictable and reproducible fashion, saving you precious time and money. It is taken from chapter three of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259).
Development and Build System with ANT (Page 1 of 11 )
Our “Age of Anxiety” is, in great part, the result of trying to do today’s job with yesterday’s tools—with yesterday’s concepts.
SOFTWARE DEVELOPMENT is a creative, fluid endeavor. In order to develop good software, developers need tools that will enable them to work effectively as individuals and as part of a team. Software development is all about people; people building tools for other people. One emerging realization of most modern methodologies is that people are the most important factor, regardless of methodology, and that every developer works differently but all of them have the same goal in mind: to create working software that satisfies a need.
In Chapter 2 we emphasized that methodologies are independent of tools, yet a tool that supports your chosen methodology will likely increase your team’s productivity. Very few developers like to have a process or methodology imposed on them. By making the processes and practices supporting a given methodology transparent and mostly automatic, a team of developers can work as an orchestra against the backdrop of a supporting set of best practices.
The contributions of the Open Source community have greatly enhanced the way Java developers perform their daily work. Nowadays, for most aspects of the development process there seems to be an offering from the Open Source community, which is ready to take on the task of simplifying the job of developers worldwide. The rapid evolution of the Open Source tool market has been driven by many factors, whether it’s to commoditize a market segment dominated by a commercial offering, to promote and research new ideas, or to embrace a new business model based partly on Open Source.
Development tools is probably the area you would most likely explore first when trying to incorporate Open Source in the enterprise. In this chapter you’ll learn about some of the tools that are available from the Java Open Source community and explore how they can help you create high-quality software in a predictable and reproducible fashion. The highlighted tools cover most of the critical areas of the software construction process and show how Open Source can support and enhance the productivity of a development team. With agility as your guiding principle, you’ll explore tools that can foster a productive, cost-effective environment to help enterprise developers excel at what they do.
The Build Process
The traditional definition of a build process entails converting source code into an executable deliverable. In the world of enterprise Java development this definition falls short. A production J2EE application build system will typically need to do much more than that. Some sample tasks that can be performed by a build include the following:
Version control: Obtaining the latest version of a project’s source code from a version control repository
Build plan: Determining what to build
Generate: Generating any source code from several sources such as annotated code, database tables, UML diagrams
Formatting: Correcting syntax and style
Checking: Validating syntax and style
Compiling: Generating .class files from .java files
Testing: Running automated tests
Validating: Verifying components’ validity
JavaDoc: Generating API documentation
Metrics: Generating code metrics reports
Packaging: Generating JAR, WAR, and EAR files
Deploying: Deploying applications to servers
Distributing: Distributing packaged applications
Notifying: Notifying developers and managers of important build-related events
This relatively short list of activities should give you an idea of how involved the build process can become. How many times have you heard the dreaded “But it was working just fine on my machine!” A reproducible build is of paramount importance for keeping your code base healthy and your project in a known state at all times. Having a reproducible and stable build process takes more than just having a dedicated team of developers. Without automation even a small project with few developers can rapidly get out of hand.
By using an automated build tool, developers can define the steps in the process of building their software and execute those steps reliably under different environments and circumstances. Typically such tools will account for individual configuration differences between developers’ environments and production systems. Most build tools have some sort of configuration or script that describes the build process in discrete, atomic steps.
A typical build process also covers aspects of both the production and the development stages of an application. For example, in a database-driven application, individual developers might need to initialize a database with sample data needed for testing, while in a production environment such a step would not be required.
Although integrated development environments (IDEs) have always provided a level of support for the building process, this support usually falls short of developers’ needs and expectations. Most of these build solutions aren’t portable across environments; it’s hard enough to get one developer’s IDE project file to work on any environment except for its creator’s. Not only are these facilities IDE-dependent, but they’re also very different from the work that an application assembler or deployer has to do for a production application. Common sense should tell you that the closest your development environment is to the production environment the least amount of problems you’ll have going into production. By having a build process that is consistent across development and production environments (and any other environments in between), you can eradicate many of the development difficulties of using multiple IDEs, operating systems, and Java versions.
As the build process is automated and becomes transparent to programmers, other issues such as testing and documentation generation find their way into the build process. Most developers find that they begin with a simple build system that evolves to accomplish more than simply “building.” From testing to document generation, a finely crafted build process eventually becomes a reflection of a team’s development process.
In J2EE a consistent build system brings together the roles of the application developer, assembler, and deployer. As part of the J2EE specification, Sun defined several roles in its definition of the J2EE platform. Newcomers to J2EE might quickly put themselves in one these categories and disregard the details of the other roles. But the reality is that unless you have an understanding of every role’s responsibility, your understanding of the J2EE platform will not be complete. In particular, the roles of the “application assembler” and the “application deployer” are reflected in the build process, and unless your developers can duplicate what happens in production you’re likely to experience a painful transition from development into production.