I see two issues here. 1. Regular users would want to retain the ease of simply changing the version number (in pom.xml or whatever build tool) and getting the latest jar from some repository - rebuilding your own special db classes every time there is a version change looks painful to me.
The direction I would suggest would be to generate separate db specific classes and put them into db specific packages - that way people really know what they are choosing. 2. Your source code and byte code being different becomes a problem while debugging on tools like eclipse (different line numbers). Which means that byte code modification may not be a universally loved option. My humble opinion would be to do source code parsing and generating the separate packages and their classes (source). This way you can get it done during generate sources phase - much like the jooq generator already does and dump the results into src/main/java. -Dileep On Friday, July 6, 2012 7:36:02 PM UTC+5:30, Lukas Eder wrote: > > Hi Dileep, > > > As far as I understand your question this is not about Jooq generated > code > > but about Jooq's source code itself. > > Precisely. Generated code is dialect-independent and will not be > concerned by this discussion > > > Then all this is valid only if the user downloads Jooq's source code and > > then tries to build from it, right? > > Exactly. Also, if they download the code and build it themselves, they > would have to manually invoke such a plugin. The default will be what > we have today. > > > Or do you want maven to mutate the dowloaded jar file somehow? > > No, what you download from SourceForge and from Maven Central will not > be affected. You would have to build jOOQ yourself. > > Cheers > Lukas > > 2012/7/6 Dileep Hareendran <[email protected]>: > > Lukas, > > As far as I understand your question this is not about Jooq generated > code > > but about Jooq's source code itself. > > > > Then all this is valid only if the user downloads Jooq's source code and > > then tries to build from it, right? > > Or do you want maven to mutate the dowloaded jar file somehow? > > > > -Dileep > > > > > > On Sunday, July 1, 2012 8:21:24 PM UTC+5:30, Lukas Eder wrote: > >> > >> As jOOQ's API is growing with new functionality and new > >> vendor-specific SQL extensions support, using the API becomes more and > >> more challenging. In order to handle compatibility among various > >> databases, I had added the org.jooq.Support annotation in release > >> 2.0.2. The purpose of this annotation is to document all the SQL > >> dialects supporting any given SQL clause / function. See more details > >> here: > >> - http://www.jooq.org/javadoc/latest/org/jooq/Support.html > >> > >> Now, in the course of this GitHub issue here: > >> - https://github.com/jOOQ/jOOQ/issues/18 > >> > >> ...the current strategy was reviewed and aligned with an idea that I > >> had previously mentioned on this user group. It would be nice if a > >> user using Oracle and MySQL could pre-process the jOOQ source code > >> using a dedicated Maven plugin, deprecating all API elements that are > >> not supported by both Oracle and MySQL. This would then lead to the > >> intersection of all API subsets that are available in either database. > >> Of course, this is also useful for users using only one database, or > >> more than two databases with jOOQ. This idea was previously discussed > >> here: > >> - https://sourceforge.net/apps/trac/jooq/ticket/1027 > >> - https://groups.google.com/forum/#!topic/jooq-user/wJj9T-rlqy4 > >> > >> Not being a Maven expert, I wonder if anyone on this group would be > >> interested to implement such a preprocessor as a Maven plugin. >
