Am Donnerstag, 5. Juli 2012 11:12:35 UTC+2 schrieb Lukas Eder: > 1. One base class which implements only features that all databases > support > > 2. At least one extension of the base class per database + an interface > > 3. If you have features which several databases share, put these shared > > features into delegates, so you only need to implement them once > > 4. One super-mega interface that contains everything > > You're forgetting the various static methods in Factory, which behave > a bit differently with respect to type inheritance.
Which is why you shouldn't use static methods ;-) Xtend has a much better solution but that doesn't help here. And I know that we can't get rid of the static methods. > Also, think about > method return type covariance, which will cause a lot of issues when > the jOOQ DSL should be multiplied once per SQL dialect. Gili (citing > Timo Westkämper from QueryDSL) nicely explained this on GitHub Issue > #18: > https://github.com/jOOQ/jOOQ/issues/18#issuecomment-6636486 > Yeah, I know: http://java.dzone.com/articles/covariant-return-type-abyssa<http://java.dzone.com/articles/covariant-return-type-abyssal> l Considering everything, I see only one options: Write a tool that "clones" the project and strips all the methods that we don't want. So you'd run the tool and you'd get a *new* Maven project which contains only the code that you want. Should be pretty simple to do with the AST parser that I posted about since you'd just have to copy any non-java file and filter the methods by annotations and then create a new source file with toString() (more or less). Other approaches: - Create one interface per database and implement that or use a clever proxy handler -> doesn't work because of the static methods. - Strip the code inline -> That would either confuse Eclipse (you can't edit the original source code anymore) or Maven (generating source code into the folder src/*/java isn't defined behavior). Regards, A. Digulla
