db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CG Monroe (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TORQUE-50) Supporting local and add-on Generator "Override" jars
Date Wed, 09 Aug 2006 19:11:16 GMT
    [ http://issues.apache.org/jira/browse/TORQUE-50?page=comments#action_12427009 ] 
            
CG Monroe commented on TORQUE-50:
---------------------------------

Forgot to document that this change also replaces log4j with commons-logging in the ant and
maven 1.0 classpath creation section.  

All log4j references in the generator code have been migrated to common-logging.  In addition,
log4j is not included in the distribution as well. (But log4j can be defined as the implimentor
to use in the commons-logging.properties file)

> 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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message