[ http://issues.apache.org/jira/browse/TORQUE-50?page=all ]
CG Monroe updated TORQUE-50:
----------------------------
Attachment: Generator Override Support.zip
Change Log for Generator Override Support
G. Monroe 9 Aug 2006
build-torque.xml
Added Ant tasks to the torque-class path building stage to use
*override.jar and a templates directory first in the classpath
plugin-jelly
Same mods as for build-torque except added a case if torque.lib.dir
was not set (Maven doesn't require this)
navigation.xml
Added a Custom Generation Item in the Other How Tos section.
customizing-generator-howto.xml
New How To that contains info on how to use the modifications to the
build scripts, pointers on modifying the generation process, and
guidelines for creating a User Contributed Torque Add On.
> 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: Generator, Maven-Plugin, Documentation
> Affects Versions: 3.2.1
> Reporter: CG Monroe
> Priority: Minor
> Fix For: 3.2.1
>
> Attachments: Generator Override Support.zip
>
>
> <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]
