db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: Proposal: Supporting local and add-on Generator "Override" jars
Date Mon, 07 Aug 2006 14:38:07 GMT
> Thomas Fischer said:
> This seems good to me. Two minor ponts though:
> - Is there a reason that the jars should be called 
> *override.jar ? I'd  find it more natural if all the 
> jars in the override directory would be considered.

I'd like that too but the problem is that Ant's 
Fileset task requires a valid directory on it's dir=
attribute or it throws a build stopping exception.
Ant does not have a way to wrap non-target tasks in
a conditional. 

To make sure the build works if the override directory
is not set, I was planning on using the torque.lib.dir
setting. If this is not valid, then the build will 
definitely fail anyway.

If the override fileset included *.jar rather than a
specific subset like *override.jar, and the default
lib directory has a lot of old versions of Torque 
dependancies, problems can occure.  This is why the 
current build scripts specifically loads required 
versions first (according to the comments).

I could make the default directory be some other 
directory but what if this has odd jars in it?  Or 
I could force the creation a default override 
directory. But I don't really like creating directories
in other peoples projects.  And what if there is a 
typo in the override setting?  The misstyped dir gets
created, things seem to be generated, but the expected
overrides don't work.  Confusing and hard to debug.

I'm open to suggestions on how to determine an 
existing safe directory for the default case or 
someone who knows a way to get Ant to behave 

> - Perhaps it would make sense to use two different 
> build properties, one for the jar directory, and one 
> for the unpacked directory.  But I do not think they 
> are crucial, so whatever seems fit to you...

Hmm, I can see it both ways.  For now, I think I'll 
just keep it simple with one extra setting.  The 
extra complexity might help folks developing stuff
but confuse folks who just want to install an add-on
and code.  Developers should be able to mod special
stuff like this if they need to.

> Would you mind to create a patch, together with the 
> necessary documentation ?

I was planning to.  I was thinking about doing this
as a quick Overriding Templatate How-To with a user
section and a developer section with some pointers 
to Velocity docs and some hints about passing
> As concerning Maven 2, there will be a maven2 plugin 
> in the following release. However, as maven 2 does 
> not yet support class path ordering as it seems 
> overriding would not seem possible for maven at the 
> moment. I'll have to check about using the classpath 
> in the maven 2 plugin anyway, cannot remember if it 
> is supported or not.

( I need to find a good emoticon to indicate when I'm
being facetious/half serious.. I knew Maven 2 was 
coming, just trying to get out of learning it...lol.
You guys keep nudging the Torque Ant evangalist into 
Maven 8p )

I'll look at it from my perspective as well.  But the
initial version will probably not include Maven2.

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are confidential communication
or may otherwise be privileged or confidential and are intended solely for the individual
or entity to whom they are addressed.  If you are not the intended recipient you may not rely
on the contents of this email or any attachments, and we ask that you  please not read, copy
or retransmit this communication, but reply to the sender and destroy the email, its contents,
and all copies thereof immediately.  Any unauthorized dissemination, distribution or copying
of this communication is strictly prohibited.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message