Home arrow Java arrow Development and Build System with ANT
JAVA

Development and Build System with ANT


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).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 25
September 08, 2005
TABLE OF CONTENTS:
  1. · Development and Build System with ANT
  2. · Continuous Integration
  3. · Automating the Build Process with Apache’s Ant
  4. · Introduction to Ant
  5. · More on Targets
  6. · Properties
  7. · Case Study: Building the Technology Conference Management System with Ant
  8. · JavaDoc Generation
  9. · Checking Code Conventions with Checkstyle
  10. · Generating Source-Code Metrics
  11. · The all Target

print this article
SEARCH DEVARTICLES

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.

—Marshall McLuhan1

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.


blog comments powered by Disqus
JAVA ARTICLES

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials