> 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).
That's where my Maven understanding stops... > I'm also not sure if that's the correct approach. "correct" is subjective in this case. It's a workaround that can help many jOOQ users. But it may feel a bit weird to use deprecation for the purpose of communicating database compatibility. > 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 You're forgetting the various static methods in Factory, which behave a bit differently with respect to type inheritance. 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 > 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. That certainly works for single-database users. But I want to resolve the use-case, where a jOOQ user uses jOOQ with Oracle AND MySQL. I'd have to create "API intersection" interfaces for every possible combination of SQL dialects. 13 dialects... you do the math :-) > Lastly, users which really don't care or which use several databases can use > the mega interface. This would correspond to the "API union", which is OK for users who don't care. But users who do care ("several databases") want an "API intersection" > 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. Yes, an Eclipse compiler plugin checking on the org.jooq.Support annotations would be a nice tool, too Cheers Lukas
