Hi, I think it's generally a good feature to have. The patch is a bit large however, so it's not so easy for me to apply it. To review it, it will take quite a long time. The general approach looks good (but I didn't apply the patch on my side yet). It's also very good to have test cases.
If it runs out the h2.jar file gets too large because of this change, I think we would need "conditional compilation" (as already used for a few features, using "//#"), plus maybe filtering classes when creating the jar file. There is a bit "magic" in the form of source code templates (automatically adding a header and a footer to the source code), that already exists for Java functions. Maybe using resources instead of hardcoding the templates would simplify things. Similar to the .jsp files for the H2 Console. There are multiple ways to continue now. One is: I apply the patch and go through all the changes. This will take quite a long time I guess. Another approach is: split the patch into multiple smaller patches. One patch contains just the refactorings (Utils.java to ClassUtils.java). Another patch possibly adding support for Groovy. It doesn't matter that much how to split the patch, only that each individual patch should result in a complete and testable project. Regards, Thomas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to h2-datab...@googlegroups.com. To unsubscribe from this group, send email to h2-database+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
