I think this sounds good. All the torque properties you've indicated
should be overideable in the torque build.properties file such as
property "torque.target.sql.dir". This would greately simplify
embedding torque into a project.
It would be nice to simply have the build.properties file in your
project. you would then run:
cd /somewhere/torqueDist
ant -buildfile torque-build.xml -Dpropfile=/app/torque/build.properties
The application would only contain the torque properties file. This
would make the application less sensitive to new versions of Torque.
Byron
Stephen Haberman wrote:
> Yeah, yeah, here I go again with wanting to re-structure the
> build-torque.xml file. I got motivated again because I am getting ready
> to patch together the standalone build-torque.xml I posted awhile ago
> and the -classpath patch changes that I posted also awhile ago. And so
> while I'm spending the time, I might as well do it right.
>
> My goal is: a build-torque.xml that can adapt to how it's being used.
> E.g. you can use it:
>
> - In it's own per-project directory in your source tree, with all of the
> templates extracted below it, just like in the tutorials.
>
> - In it's own machine-wide directory, with all of the templates
> extracted below it. Not in the source tree, but extensible enough to put
> the resulting Java/sql files where you want them to, not just
> outputDirectory/sql.
>
> - The build-torque.xml file all by itself in a project, reading the
> templates from the classpath.
>
> As I see it, one of the first steps in doing this is to rename the
> current outputDirectory properties so that they're not hard coded so
> that users can control where they're files end up in the source tree.
>
> So, here's what I had been using:
>
> torque.home = .
> torque.project = ${project}
> torque.database = ${database}
> torque.outputDirectory = ${torque.home}/${outputDirectory}
> torque.schemaDirectory = ${torque.home}/${schemaDirectory}
> torque.target.java.dir = ${torque.outputDirectory}/java
> torque.target.sql.dir = ${torque.outputDirectory}/sql
> torque.target.doc.dir = ${torque.outputDirectory}/doc
> torque.target.javadoc.dir = ${torque.outputDirectory}/javadoc
> torque.target.ojb.dir = ${torque.outputDirectory}/ojb
> torque.target.build.dir = ${torque.home}/bin/classes
> torque.templatePath = ${torque.home}/templates
> torque.documentationFormat = ${documentationFormat}
> torque.lib.dir = lib
> idTableXMLFile =
>
> This shows how the new properties match to their old ones.
>
> Ideally projects would use the new properties, as they're more
> customizable than the old ones. However, doing this sort of assignment
> from old to new also allows old build.properties files to be used. If
> the user has the new torque.outputDirectory or torque.target.javadoc.dir
> set, it'll be used, but if not, the script would fall back to the legacy
> default of ${torque.home}/${outputDirectory} or
> ${outputDirectory}/javadoc.
>
> So, instead of supplying one big patch for this standalone thing and
> having no one respond, I'd like to step through it and get input on what
> everyone wants to see. So please, tell me, this is good? Bad?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
