Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Java Tools for Extreme programming mastering open source tools including - Hightower R.

Hightower R. Java Tools for Extreme programming mastering open source tools including - Wiley publishing , 2002. - 417 p.
ISBN: 0-471-20708
Download (direct link): javatoolsforextremeprog2002.pdf
Previous << 1 .. 26 27 28 29 30 31 < 32 > 33 34 35 36 37 38 .. 159 >> Next

run:
[echo] /usr/home/production/lib /usr/home/production/classes What happens when you have deployment descriptor files that differ between the two environments? You use filters, as discussed in the next section and Chapter 6.
Using Filters
Filters can be used to replace tokens in a file with their proper values for that particular environment. One scenario that comes to mind follows the example in the previous section. Let's say we have a production database and a development database. When deploying to production or development, we want the values in our deployment descriptor or properties file that refer to the JDBC URL of the needed database to refer to the correct database:
<project name="hello" default="run">
<target name="setupProduction" if="production">
<filter token="jdbc_url" value="jdbc::production"/>
</target>
<target name="setupDevelopment" unless="production">
<filter token="jdbc_url" value="jdbc::development"/>
</target>
<target name="setup" depends="setupProduction,setupDevelopment"/>
88
<target name="run" depends="setup">
<copy todir="/usr/home/production/properties" filtering="true"> <fileset dir="/cvs/src/properties"/>
</copy>
</target>
</project>
Again, setupProduction and setupDevelopment are executed conditionally based on the production property. But this time, instead of setting properties, they set filters as follows:
<target name="setupProduction" if="production">
<filter token="jdbc_url" value="jdbc::production"/>
</target>
<target name="setupDevelopment" unless="production">
<filter token="jdbc_url" value="jdbc::development"/>
</target>
The filter in the setupProduction target sets jdbc_url to jdbc::production. The filter in the setupDevelopment target sets jdbc_url to jdbc::development. The copy task in the run target turns on filtering, which applies the filter to all in the fileset. Thus, the copy task will copy recursively all the files from the /cvs/src/properties directory into the /usr/home/production/properties directory, replacing all the occurrences of the string "@jdbc_url@" with "jdbc::production" if the "production" property is set or jdbc::development if the "production" property is not set. You'll see more examples of this technique in Chapter 6.
Nested Builds
Each project (library module, Web application, set of Enterprise JavaBeans, applet, and so on) should have its own directory with its own buildfile. A large project can depend on lots of other projects. Ant allows one Ant buildfile to call another. Thus, you may have an Ant file that calls a hierarchy of other Ant buildfiles. You can nest buildfiles using this method to build many projects and their dependent projects.
The ant task runs a specified buildfile. The ant task can be used to build subprojects and related projects. You have the option of specifying the buildfile name or just the directory (the file build.xml in the directory specified by the "dir" attribute is used). You also have the option of specifying a particular target to execute. If you do not specify a target to execute, the default target is used. Any properties that you set in the called project are available to the nested buildfile.
The following are some examples of calling another Ant buildfile from your Ant buildfile. We can call a buildfile from the current buildfile and pass a property as follows:
<ant antfile="./hello/build.xml">
<property name="production" value="true"/>
</ant>
We can call a buildfile from the current buildfile. When you call the ant task, if you don't specify an antfile attribute, then it will use ./hello/build.xml) as follows:<ant dir="./hello"/>
Notice above that we only specified the directory. The default buildfile is build.xml; if you only specify the directory, then build.xml is assumed.
B9
We can call a buildfile from the current buildfile and specify that the run target should execute (if the run target was not the default target, it would execute anyway) as follows:
<ant antfile="./hello/build.xml" target="run"/>
Summary
This chapter covered the basics of using Ant and the concepts of buildfiles, projects, targets, conditional targets, tasks, filesets, filters, nested buildfiles, and properties. Our discussion included the basics styles and naming conventions for Ant buildfiles.
The chapter also explained the importance of Ant in its relationship to continuous integration. Chapter 6 uses these basics to build sample J2EE applications. By the end of Chapters 5 and 6, you should be able to build and deploy the following: Enterprise JavaBeans, Web components (servlets and JSPs), applets, and Java applications. You should also be able to combine these elements into projects and subprojects that can be easily managed and deployed on both a production and development environment.
Chapter 5: Building Java Applications with Ant
Overview
This chapter explains the techniques involved in using Ant to build and deploy Java applications in an orchestrated fashion. Once you understand these fundamental techniques, you will be ready for the complexities of Chapter 6, "Building J2EE Applications with Ant," in which we build a Model 2 application complete with EJBs, servlets, and JSPs.
Previous << 1 .. 26 27 28 29 30 31 < 32 > 33 34 35 36 37 38 .. 159 >> Next