Creating Portable Build Processes
As we’ve already seen, using Ant for enterprise development projects raises some potential portability issues with our buildfiles. Certain targets, such as deploying an application archive to an application server, are necessarily specific to a type of J2EE server and will need to be changed if another type of application server is used to run the application. These kinds of portability issues become even more complicated when you need to support multiple development and deployment environments concurrently and are multiplied again when your project makes use of a source code repository:
Developer environments often vary in terms of the locations of support libraries, application server directories, and so on. This requires the editing of the build properties to suit the local development environment. If these build properties are stored in a file that’s checked in with the project code in a code repository, these changes need to be made each time the project code is checked out and undone before the development changes are checked back in.
In typical build/test/release development processes, the software being produced needs to be deployed and executed in one of several server environments, depending on the stage of the process. These environments are typically configured in different locations and may have different internal configurations. In addition, the application itself may need to be configured differently depending on the deployment environment—locations ...
Get Java Enterprise in a Nutshell, Third Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.