On Tue, Aug 31, 2010 at 12:27 AM, Antonio Petrelli <[email protected]> wrote: > 2010/8/31 Nathan Bubna <[email protected]>: >>> - 1 - >>> The test organization is strange: the .java test files are considered >>> resources, parsed just to substitute two variables in one file, and >>> then compiled. These variables are pointing to the template and target >>> directory. >>> The best thing to do is using to access resources from classpath and >>> writing to temporary files. If file access is needed on read phase, >>> they should be copied into a temporary file and then accessed from >>> there. >>> A second solution, easier but I don't like it too much, is to create a >>> .properties file containing these variables and substitute them only >>> in this file. >> >> Actually, i would prefer to see most of those old tests re-written to >> be string-based, not file-based and ditch the substitution, if >> possible. Though, i imagine we'll still need to do something like >> that to test the FileResourceLoader, most VTL-centric tests should not >> use external resources. For where we do need to load files, i don't >> greatly care how it is done. All of these solutions seem acceptable >> to me, let whoever does the work decide. > > This is outdated, sorry, I replaced everything with system properties > (like you did in other Velocity subprojects) and they work like a > charm. > >>> - 2 - >>> Currently the parser code has been generated previously and then >>> committed into the repository. Probably, the best approach is to >>> generate it at build time, using the JavaCC Maven plugin. >> >> +1 that would be fantastic > > Sure, but *after* there is consensus about promoting from the sandbox > to the main trunk.
agreed. no point in doing it otherwise! > Antonio > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
