> 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 differently. > - 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 properties. > > 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 > >(http://jira.codehaus.org/browse/MNG-1412), > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
