Ant is a very popular tool for building Java projects. It is similar to the make command, but is Java-centric and has more modern features. Ant is open-source, and can be downloaded from Apache's Ant web page at http://jakarta.apache.org/ant/. Ant has become the de-facto standard build tool for Java, and many commercial integrated development environments provide some support for using ant build files. The remainder of this section assumes familiarity with writing Ant build.xml files.
Kodo provides pre-built Ant task definitions for all bundled tools:
The source code for all the ant tasks is provided with the distribution under the src directory. This allows developers to customize various aspects of the ant tasks in order to better integrate into their development environment.
All Kodo tasks accept a nested <config> element, which defines the configuration environment in which the specified task will run. The attributes for the <config> tag are defined by the JDBCConfiguration bean methods. Note that excluding the <config> element will cause the Ant task to use the default system configuration mechanism, such as the configuration defined in the kodo.properties file.
Following is an example of how the nested <config> tag can be used in a build.xml file:
Example 15.1. Using the <config> Ant Tag
<mappingtool action="refresh">
<fileset dir="${basedir}">
<include name="**/*.jdo" />
</fileset>
<config connectionUserName="scott" connectionPassword="tiger"
licenseKey="1234-5678-90ab-cdef"
connectionURL="jdbc:oracle:thin:@saturn:1521:solarsid"
connectionDriverName="oracle.jdbc.driver.OracleDriver" />
</mappingtool>
It is also possible to specify a properties or propertiesFile attribute to the <config> tag, which will be used to locate a properties resource or file. The resource will be loaded relative to the current CLASSPATH.
Example 15.2. Using the Properties Attribute of the <config> Tag
<mappingtool action="refresh">
<fileset dir="${basedir}">
<include name="**/*.jdo"/>
</fileset>
<config properties="kodo-dev.properties"/>
</schematool>
Example 15.3. Using the PropertiesFile Attribute of the <config> Tag
<mappingtool action="refresh">
<fileset dir="${basedir}">
<include name="**/*.jdo"/>
</fileset>
<config propertiesFile="../conf/kodo-dev.properties"/>
</schematool>
Tasks can also take a nested <classpath> element, which can be used if the default classpath is not desired. The <classpath> argument behaves the same as it does for ant's standard <javac> element. It is sometimes the case that projects are compiled to a separate directory than the source tree. If the target path for compiled classes is not included in the project's classpath, then a <classpath> element that includes the target class directory needs to be included so the enhancer and mapping tool can locate the relevant classes.
Following is an example of using a <classpath> tag:
Example 15.4. Using the <classpath> Ant Tag
<jdoc>
<fileset dir="${basedir}/source">
<include name="**/*.jdo" />
</fileset>
<classpath>
<pathelement location="${basedir}/classes"/>
<pathelement location="${basedir}/source"/>
<pathelement path="${java.class.path}"/>
</classpath>
</jdoc>
Finally, tasks that invoke code-generation tools like the application identity tool and reverse mapping tool accept a nested <codeformat> element. See the code formatting documentation for a list of code formatting attributes.
The JDO enhancer task allows you to invoke the JDO enhancer directly from within the Ant build process. It takes a nested <fileset> tag to specify the files that should be processed. You can specify .java, .jdo, or .class files. The task's parameters correspond exactly to the long versions of the command-line arguments to jdoc .
Following is an example of using the JDO enhancer task in a build.xml file:
Example 15.6. Invoking the JDO Enhancer from Ant
<target name="enhance">
<!-- define the jdoc task; this can be done at the top of the -->
<!-- build.xml file, so it will be available for all targets -->
<taskdef name="jdoc" classname="kodo.ant.JDOEnhancerTask"/>
<!-- invoke enhancer on all .jdo files below the current directory -->
<jdoc>
<fileset dir=".">
<include name="**/*.jdo" />
</fileset>
</jdoc>
</target>
The application identity tool task allows you to invoke the application identity tool directly from within the Ant build process. It takes a nested <fileset> tag to specify the files that should be processed. You can specify .java, .jdo, or .class files. The task's parameters correspond exactly to the long versions of the command-line arguments to the appidtool.
Following is an example of using the application identity tool task in a build.xml file:
Example 15.7. Invoking the Application Identity Tool from Ant
<target name="appids">
<!-- define the appidtool task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="appidtool" classname="kodo.ant.ApplicationIdToolTask"/>
<!-- invoke tool on all .jdo files below the current directory -->
<appidtool>
<fileset dir=".">
<include name="**/*.jdo" />
</fileset>
<codeformat spaceBeforeParen="true" braceOnSameLine="false"/>
</appidtool>
</target>
The JDO metadata tool task allows you to invoke the JDO metadata tool directly from within the Ant build process. We do not recommend that you regenerate your JDO metadata often, but the task is available nonetheless. It takes a nested <fileset> tag to specify the files that should be processed. You can specify .java or .class files. The task's parameters correspond exactly to the long versions of the command-line arguments to the metadatatool.
Following is an example of using the JDO metadata tool task in a build.xml file:
Example 15.8. Invoking the JDO Metadata Tool from Ant
<target name="genmetadata">
<!-- define the metadatatool task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="metadatatool" classname="kodo.ant.JDOMetaDataToolTask"/>
<!-- invoke tool on all *PC.java files in the current directory -->
<metadatatool file="package.jdo">
<fileset dir=".">
<include name="*PC.java"/>
</fileset>
</metadatatool>
</target>
The mapping tool task allows you to directly invoke the mapping tool from within the Ant build process. It is useful for making sure that the database schema and object-relational mapping data is always synchronized with your persistent class definitions, without needing to remember to invoke the mapping tool manually. The task's parameters correspond exactly to the long versions of the command-line arguments to the mappingtool .
Following is an example of a build.xml target that invokes the mapping tool:
Example 15.9. Invoking the Mapping Tool from Ant
<target name="refresh">
<!-- define the mappingtool task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="mappingtool" classname="kodo.jdbc.ant.MappingToolTask"/>
<!-- add the schema components for all .jdo files below the -->
<!-- current directory -->
<mappingtool action="refresh">
<fileset dir=".">
<include name="**/*.jdo" />
</fileset>
</mappingtool>
</target>
The reverse mapping tool task allows you to directly invoke the reverse mapping tool from within Ant. While many users will only run the reverse mapping process once, others will make it part of their build process. The task's parameters correspond exactly to the long versions of the command-line arguments to the reversemappingtool.
Following is an example of a build.xml target that invokes the reverse mapping tool:
Example 15.10. Invoking the Reverse Mapping Tool from Ant
<target name="reversemap">
<!-- define the reversemappingtool task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="reversemappingtool"
classname="kodo.jdbc.ant.ReverseMappingToolTask"/>
<!-- reverse map the entire database -->
<reversemappingtool package="com.xyz.jdo" directory="${basedir}/src"
customizerProperties="${basedir}/conf/reverse.properties">
<codeformat tabSpaces="4" spaceBeforeParen="true" braceOnSameLine="false"/>
</reversemappingtool>
</target>
The schema tool task allows you to directly invoke the schema tool from within the Ant build process. The task's parameters correspond exactly to the long versions of the command-line arguments to the schematool .
Following is an example of a build.xml target that invokes the schema tool:
Example 15.11. Invoking the Schema Tool from Ant
<target name="schema">
<!-- define the schematool task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="schematool" classname="kodo.jdbc.ant.SchemaToolTask"/>
<!-- add the schema components for all .schema files below the -->
<!-- current directory -->
<schematool action="add">
<fileset dir=".">
<include name="**/*.schema" />
</fileset>
</schematool>
</target>
The schema generator task allows you to directly invoke the schema tool from within the Ant build process. The task's parameters correspond exactly to the long versions of the command-line arguments to schemagen .
Following is an example of a build.xml target that invokes the schema generator:
Example 15.12. Invoking the Schema Generator from Ant
<target name="genschema">
<!-- define the schemagen task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="schemagen" classname="kodo.jdbc.ant.SchemaGeneratorTask"/>
<!-- generate the database schema to the schema.xml file -->
<schemagen file="${basedir}/schema.xml"/>
</target>