Thanks for your suggestions. One small problem we would have to overcome is that maven does not make test code available from one project to another project that expresses a dependency on it. Moving some part of the test code into the implementation wouldn't be nice from the point of view the run-time artifacts that are distributed. Separating testing out into higher level projects means we wouldn't get the automatic benefits of an immediate notification of the introduction of an issue when building with maven.
We could insert an intermediate "test-core" project, that is not part of the SDO distribution, either between the API project and the lib projects (in dependency terms) or between the lib and the impl projects. The bodies of the tests could then be implemented in the main source folder hierarchy of that project (as opposed to the test code hierarchy). The test bodies would be in abstract classes with template methods as you suggest. The lib, impl and tools-tests projects can then declare a test scope dependency on that new project, and the test programs be implemented in the test code hierarchy of the implementation projects, extending the behaviour of the test programs in the new project.
Similarly the tools-test project could declare a dependency on the new project. There would be a deficiency here that I haven't got my head round yet. If we want a single location for the schemas, then they would have to be in the new project. This means I think that we wouldn't be able to rely on maven's "generate" phase to handle the generation for us in the tools-test project. One possibility would be to use svn's "externals" property to make the same schema files available to the test resources of both projects, but that may be a trip hazard.