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.xml or kodo.properties file.

Following is an example of how to use the nested config tag in a build.xml file:

<mappingtool>
  <fileset dir="${basedir}">
    <include name="**/model/*.java" />
  </fileset>
  <config connectionUserName="scott" connectionPassword="tiger"
    connectionURL="jdbc:oracle:thin:@saturn:1521:solarsid"
    connectionDriverName="oracle.jdbc.driver.OracleDriver" />
</mappingtool>

It is also possible to specify a properties or propertiesFile attribute on the config tag, which will be used to locate a properties resource or file. The resource will be loaded relative to the current CLASSPATH.

<mappingtool>
  <fileset dir="${basedir}">
    <include name="**/model/*.java"/>
  </fileset>
  <config properties="kodo-dev.properties"/>
</mappingtool>

<mappingtool>
  <fileset dir="${basedir}">
    <include name="**/model/*.java"/>
  </fileset>
  <config propertiesFile="../conf/kodo-dev.properties"/>
</mappingtool>

Tasks also accept a nested classpath element, which you can use in place of the default classpath. 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:

<kodoc>
  <fileset dir="${basedir}/source">
    <include name="**/model/*.java" />
  </fileset>
  <classpath>
    <pathelement location="${basedir}/classes"/>
    <pathelement location="${basedir}/source"/>
    <pathelement path="${java.class.path}"/>
  </classpath>
</kodoc>

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 in Section 2.4.1, “Code Formatting” for a list of code formatting attributes.

<reversemappingtool package="com.xyz.jdo" directory="${basedir}/src">
  <codeformat tabSpaces="4" spaceBeforeParen="true" braceOnSameLine="false"/>
</reversemappingtool>

Kodo's Ant tasks all utilize BEA licensing system and expect to find license.bea available in the classpath. Be sure that this file is avaialble to every task. For futher details, see Section 2.2, “License Configuration”.

The enhancer task allows you to invoke the Kodo enhancer directly from within the Ant build process. The task's parameters correspond exactly to the long versions of the command-line arguments to kodoc.

	Important
	Set the tasks jdoEnhance attribute to true to perform JDO enhancement.

The enhancer task accepts a nested fileset tag to specify the files that should be processed. You can specify .java, .jdo, or .class files. If you do not specify any files, the task will run on the classes listed in your kodo.MetaDataFactory property.

Following is an example of using the enhancer task in a build.xml file:

<target name="enhance">
  <!-- define the kodoc task; this can be done at the top of the    -->
  <!-- build.xml file, so it will be available for all targets      -->
  <taskdef name="kodoc" classname="kodo.ant.PCEnhancerTask"/>

  <!-- invoke enhancer on all .jdo files below the current directory -->
  <kodoc jdoEnhance="true">
    <fileset dir=".">
      <include name="**/model/*.java" />
    </fileset>
  </kodoc>
</target>

The application identity tool task allows you to invoke the application identity tool directly from within the Ant build process. The task's parameters correspond exactly to the long versions of the command-line arguments to appidtool.

The application identity tool task accepts a nested fileset tag to specify the files that should be processed. You can specify .java, .jdo, or .class files. If you do not specify any files, the task will run on the classes listed in your kodo.MetaDataFactory property.

Following is an example of using the application identity tool task in a build.xml file:

<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="**/model/*.java" />
    </fileset>
    <codeformat spaceBeforeParen="true" braceOnSameLine="false"/>
  </appidtool>
</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.

The mapping tool task accepts a nested fileset tag to specify the files that should be processed. You can specify .java, .jdo, or .class files. If you do not specify any files, the task will run on the classes listed in your kodo.MetaDataFactory property.

Following is an example of a build.xml target that invokes the mapping tool:

<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="buildSchema">
    <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:

<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.model" 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:

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