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. Antonio --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
