[ http://issues.apache.org/jira/browse/TORQUE-50?page=all ]
CG Monroe updated TORQUE-50:
----------------------------
Attachment: custom-templates.xml
how-templates-work.xml
Some documentation changes for these files in the: generator/xdocs directory.
custom-templates:
Some minor edits.
how-templates-work:
Expansion to cover the topic better. Now has the following topics:
1. Introduction
2. Process Overview
3. Template Files
4. Template Variables
5. The XML Custom Option Element
Note that section 5 covers the new "Option" schema element submitted as part of
the Torque-27 issue. Seemed like a good place to point it out.
> Supporting local and add-on Generator "Override" jars
> -----------------------------------------------------
>
> Key: TORQUE-50
> URL: http://issues.apache.org/jira/browse/TORQUE-50
> Project: Torque
> Issue Type: Improvement
> Components: Documentation, Generator, Maven-Plugin
> Affects Versions: 3.2.1
> Reporter: CG Monroe
> Priority: Minor
> Fix For: 3.2.1
>
> Attachments: custom-templates.xml, Generator Override Support.zip,
> how-templates-work.xml
>
>
> <From an e-mail proposal talked about on the torque-dev list>
> I've been looking at how to package, document, contribute
> my betwixt map/dtd generation code. As Thomas pointed out,
> it's not truely mainstream Torque but might be a useful
> addon. Anyway, this got me thinking about how to best
> support template and/or generator local modifications or
> add-on.
>
> If the generator build scripts supplied by the Torque
> distro had classpaths that first tried to add any
> *-override.jar files before the distro files, then
> Templates and generator classes could easily be locally
> overriden. This is trivial to do with the Ant
> torque-build.xml. I assume that it would be easy in Maven?
>
> If no *override.jar files exist, it's a standard install.
> But if you've got local changes to implement or want to
> use a supplied add-on, just add *override.jar files to the
> correct directory(s) and use the standard generation
> processes.
>
> IMHO, this seems cleaner than trying to maintain a full
> customized template or generator distros. If a new
> version comes out, just grab the standard, check for
> any gottcha's between it and your modified code, add back
> in your override jars. All the benefits of a new version
> with your local mods included.
>
> In a lot of cases, like changes to sql generation
> templates (e.g. MySQL Table options ) or new db
> adaptor support (like Informix/MSSQL7), this will be
> very easy. These areas don't change a lot or are
> mostly new templates.
>
> It also allows for easier add-on contributions. An add-on
> could be supplied as a set of jars that are simply put in
> the correct directories using common How-To instructions.
> The add-in supplier just needs to document any additional
> settings.
>
> It's not perfect since add-on's can override each other
> and break... but it's better than it was.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
