Hello Dileep, > 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.
As I said. That's what regular users will keep doing. This thread is about an *optional* way for users who build jOOQ themselves (i.e. check out the sources, integrate jOOQ as a source module in their own project). All other users download standard binaries and will not profit from such a feature. > 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. This isn't about db specific generated classes. Generated classes are not db specific. If you mean db specific API classes, this thread and others have sufficiently shown that such an approach is difficult to implement. > 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. As previously discussed on this thread: This is not about byte code modification. If such a solution will be implemented, users who build jOOQ themselves will use a tool to patch jOOQ source code, before they build jOOQ. This means that a customised, modified version of jOOQ will be built with matching source, javadoc, and binary .jar files. > 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. That's exactly what I had in mind. This thread is about finding out, whether precisely that can be done with Maven. Cheers Lukas
