> > Not being a Maven expert, I wonder if anyone on this group would be > interested to implement such a preprocessor as a Maven plugin. >
That might be possible but you'd have to move all sources outside of the src/main/java folder because the compiler will look into there (unless configured to look elsewhere which is a mess). I'm also not sure if that's the correct approach. When I learned OOP, the idea was to have a common base class which implements the common features and then extensions which implement special cases. In your case: 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 Users which are locked to a certain database can access jOOQ with the interface for their database. The other methods might be there but they can't "see" them because of the interface. Alternatively, they could use the implementation which only has the supported methods. Lastly, users which really don't care or which use several databases can use the mega interface. That said, maybe a better approach would be to write a test case that analyzes the AST ( http://blog.pdark.de/2010/11/05/using-eclipse-to-parse-java-code/), locates which jOOQ methods are called and then verifies the annotations against a list of allowed databases.
