A good build process is more than just a script for compiling software. Instead, a build process performs and automates many of the common activities on a project. Examples of common activities include the following:
Having a ready-made build process in place before a project commences is a major time-saver. Build processes are sophisticated pieces of software that require careful design, construction, and testing. Consequently, investment in the development of build processes that are reusable between projects is a key factor in the makeup of a company's adaptive foundation for rapid development.
The next sections offer some guidelines for creating a build process that is conducive to the practice of rapid development.
Designing a Build Process
Like software systems, build systems require careful design. Regardless of the type of software under development, the requirements for a build system tend to be common between projects. Here is a summary of some of the main requirements:
These requirements are common to most software projects. The development of enterprise-level software introduces a further set of requirements peculiar to the J2EE platform.
J2EE Build Requirements
The build process for a conventional Java-based application often builds only a single target, thereby making for a simple build environment. Unfortunately, a J2EE application is not so straightforward; it involves numerous intricate steps to generate multiple targets.
Unlike its J2SE counterpart, a J2EE application comprises a set of components, which collectively make up the whole application. Each component can have vastly different build requirements. EJB components require specialized compilation tasks for the generation of stub and skeleton implementations. Code generation tools such as XDoclet are becoming increasingly popular for the effort they save, but add additional steps and complexity to the build process.
XDoclet is covered in Chapter 6.
In addition to these specialized tasks, J2EE components require packaging. EJB components are wrapped in JAR files, and Web applications are packed in a Web archive (WAR) file. Finally, all components can be bundled in an enterprise resource file (EAR), the format recommended for J2EE deployments by application servers.
To summarize, a J2EE build typically includes the following tasks, which are additional to traditional Java builds:
All of these tasks devour time. Packaging, which requires moving files around the file system into a structure where they can be bundled into a format ready for deployment, is a particularly time-consuming process. Likewise, the process of deploying components to the server and placing them in an executable state is also potentially time consuming.
Shortening the length of time spent building and deploying is a case of reducing the amount of work the build system has to undertake. This gives rise to the concept of a build system capable of performing minimal builds and minimal deployments. We consider each concept in turn.
Generating source, compiling code, and packaging binaries into JAR files are all resource-intensive tasks. If the number of times these tasks have to be performed as part of the build can be reduced, savings in build times result.
Achieving these savings involves ensuring the build system can undertake incremental tasks, building only those components impacted by a particular code change. Therefore, if a source file is changed, the build system should not have to regenerate the full system. Instead, it should be able to determine from dependency information those components affected by the change, and accordingly build, package, and deploy only those modules that are affected.
Minimal builds are only part of the story. It is also necessary to consider how a built application transitions into a state in which it can be run and tested. For J2EE solutions, this involves deploying components to the application server.
A minimal deployment approach looks to reduce the total number of steps that must be taken by the software engineer in order to deploy a change to the server. A typical worst case is that the server must be stopped, the entire application redeployed, and then the server restarted. This type of delay is unacceptable. Thankfully, most J2EE application server vendors acknowledge the importance of being able to turn around change quickly and efficiently, so they offer support for the hot deployment of applications. The practice of hot deployment requires further explanation given its importance to the build process.
What Is Hot Deployment?
Hot deployment is a concept embraced by most application server vendors and refers to the ability of the server to deploy an updated J2EE application into a live environment without having to shut down either the server or the running application.
For a production system, hot deployment has obvious benefits for system availability. For development teams, however, we require a slightly different form of hot deployment that is perhaps better called automatic deployment.
This concept has the application server continually polling for new files. On detecting a new file, the application server immediately loads the change and integrates it into the current application.
Automatic deployment is unsuitable for a production environment because the need for the server to poll its deployment directories continually is an unacceptable performance overhead.
In a fast-paced development environment, this functionality is a major timesaver for the software engineer, as no manual steps are needed for the application server to apply the software changes other than deploying the changes to the server.
Automatic deployment is a proprietary feature and is not covered by the J2EE specification, which only stipulates the deployment of EAR, WAR, JAR, and RAR files. Application servers, such as WebLogic from BEA, have gone beyond the J2EE specification and provide support for the deployment of applications in an expanded, or exploded, format rather than an archive file. This approach, which BEA recommends for deployment to its server, provides support for the minimal deployment approach.
WebLogic server supports automatic deployment if the server is running in development mode. This is achieved by setting the system property -Dweblogic.ProductionModeEnabled to false.
You must check the details of your particular application server to determine what it provides in terms of minimal and hot deployment capabilities.
Having covered some of the main requirements for a build system, we can now look at producing the build process itself. For this, we need to adopt a suitable build tool.