Hey, I had the itch today to fix torque's test build scripts. With all of the jars.list and default.properties, it was just ugly.
I'm hoping for a completely maven/JUnit-ized process that will do away with build-test.xml/jars.list/default.properties, change all of the *.profile files down to be minimalistic database settings, and allow multiple schema/property configurations. So far things are going well, though I'm stuck on how to use a jelly tag in the maven.xml file. My current approach is to have all of the schema files (e.g. bookstore, sqlTest, objTest) in rttest. And then multiple build.properties (all in rttest along with the schema files), along the lines of: build.defaults.properties build.nativeid.properties build.useClasspath.properties build.useManagers.properties And each of this is really minimalistic since we can rely on defaults, e.g. build.useManagers.properties just looks like: torque.project = rttest torque.targetPackage = org.apache.torque.test.managers torque.useManagers = true Then the process is to take all of the schema files, generate all of them against a single build.properties, say build.defaults.properties, and run unit generic unit tests (e.g. the basic bookstore save/load stuff). Then take the next properties file, say build.useClasspath.properties, regenerate all of the schemas against the new properties, run generic unit tests (the same as before) along with any unit tests in o.a.torque.test.useClasspath. These package-specific unit tests be useful for property configurations that generate different java code that the others, e.g. useManagers, so it could have it's own tests and not have the unit tests fail when the managers aren't even being generate (say in the preceeding useClasspath generation). So, while there will be lots more generation and testing going on, I think it's all for the better. Instead of relying on developers to toggle their idMethod/useXxx/etc methods, we can have x number of property configurations that we test each schema against. Any comments on what I'm doing? Hopefully I can finish this up tomorrow when the jelly thing works out. Given that this is all testing, and the current stuff is a tad broken anyway, is it okay to commit this right away? (Note that the build.xxx.properties naming convention just allows xxx to be any short description of what the configuration is testing...it could be build.testManagersButNoClasspath.properties or what not) Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
