Sounds interesting. Here is my experience:
1. Define torque.home in the build.properties, which points to a torque distribution
directory;
2. Define torque.contextPropertes in my build.xml file, like this
<property file="build.properties"/>
<property name="torque.contextProperties" value="build-torque.properties"/>
3. Define torque.om task to pass the task to torque.
<!-- Generate object files from Torque distribution required torque.home and
torque.contextProperties set in build.properties file -->
<target name="torque-om" if="torque.home">
<ant antfile="${torque.home}/build-torque.xml" target="om">
<property name="torque.lib.dir" location="${torque.home}/lib"/>
</ant>
</target>
Basically I try to minimize referencing torque in my build.xml, keeping Torque
separated from my project. The generated Java file is local in my project src/java
directory. I also checked in generated file. If you turn off Timestamp option, the
generated Java file will not change if schema file doesn't change. Compile is always
done in local src/java directory.
Howard Lin
> -----Original Message-----
> From: Bill Schneider [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 07, 2002 5:58 PM
> To: Turbine Torque Users List
> Subject: incorporating torque into a project
>
>
> We're using Torque on a variety of projects here at Vecna and
> came up with a
> strategy for incorporating Torque into our build.xml script.
> The general
> ideas are:
>
> - we reference a central install of torque for each project;
> - we include <torque-data-model> tasks directly in our
> build.xml, whose
> properties reference a torque install and output Java source
> to a directory
> of temporary source files;
> - overridden Torque classes get checked into source control
> in the project
> proper; autogenerated stuff doesn't
> - we have a build-src directory to copy all source files from
> the project
> into a temp directory immediately before compiling
> torque-generated classes
> get copied there too (have to do this to deal with
> co-dependencies between
> autogenerated Java classes and overriden ones)
> - we use the standard <uptodate> task to re-run the
> <torque-data-model> task
> on demand when torque-schema.xml is newer than anything
> Torque had spit out
>
> It has worked out pretty well so far. How does this compare
> with other
> people's experiences? Would it benefit anyone for me to spam
> the list with
> portions of our build.xml files?
>
> -- Bill
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
