After migrating your JDO metadata, you can migrate your Kodo configuration properties files. You must do this after migrating your JDO metadata so that the migrator tool can draw on your Kodo 2 mapping preferences.
The Kodo 2 properties tool can automatically migrate your configuration files. You can invoke the tool via the included kodo2properties script or via its Java class, kodo.jdbc.kodo2.Kodo2Properties. The tool also comes with an Ant task, which we present later in this section.
The tool accepts the standard set of command-line arguments defined by the configuration framework , along with the following flags:
-file/-f <stdout | output file or resource> : The path or resource name of the migrated properties file. You should only use this argument if you want to override the default behavior of overwriting the original file (after backing it up), and only if you are invoking the tool on only a single properties file.
Each additional argument to the tool should be a Kodo 2 properties file. Unless a -file argument is given, the file will be backed up to <file-name>~, and a new properties file will be generated in its place.
The Kodo 2 properties tool can also be invoked via its Ant task, kodo.jdbc.ant.Kodo2PropertiesTask. The attributes of the task correspond exactly to the long versions of the command-line argument accepted by the tool. Additionally, see the chapter on Ant integration for common configuration options available to all Kodo tasks.
Example D.4. Invoking the Kodo 2 Properties Tool from Ant
<target name="migrate-props">
<!-- define the kodo2properties task; this can be done at the top of -->
<!-- the build.xml file, so it will be available for all targets -->
<taskdef name="kodo2properties" classname="kodo.jdbc.ant.Kodo2PropertiesTask"/>
<!-- invoke tool on all the conf/kodo*.properties files -->
<kodo2properties>
<fileset dir="${basedir}/conf">
<include name="**/kodo*.properties" />
</fileset>
</kodo2properties>
</target>