Yes, the test file setup is kind of dumb. It needs a refactoring. Really, we should be able to change this so all paths are relative
Regarding your comments on oro, etc. One key thing is we need to preserve backwards compatibility, at least for the 1.x line. What this means is (a) no changes to key interfaces, and (b) must remain run-compatible with JDK 1.3. (though compiling requires JDK 1.4). Practically this means we cannot use JDK 1.4 regular expression classes. WILL On Thu, Jul 8, 2010 at 12:33 AM, Antonio Petrelli < [email protected]> wrote: > 2010/7/8 Nathan Bubna <[email protected]>: > >> * The Excalibur dependency has not been removed. > > > > but it should be > > Yes, I forgot to tell it :-D > > Other things that I forgot: > > - 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. > > - 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. > > Antonio > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
