Hello Sergey, I'm cc'ing to the user-group, as always, to share your thoughts with other users. There tends to be good feedback on rather fundamental issues like this one:
> It's a good practice. It simplifies configuration, generated source code is > always up to date, nobody can change it and commit. > You do not have keep jar files on source control, etc. > Modern IDE's understand maven life cycle and include generated source code > to classpath, so I do not see any problem here. I'm not sure if everyone will agree on this. If you need to explicitly add M2E as a plugin to your Eclipse project to generate sources needed in jOOQ, some users will probably hate me for that :-) For non-Maven users (there are many, include me as a matter of fact, M2E kills my CPU), it is already quite a pain to manually add the dependencies. So I'm really interested only in solutions where in the end, XJC-generated source code can be checked in to trunk. This source code doesn't change a lot, so I don't need to re-generate it every time. On the other hand, moving the generation from ant to the pom.xml is fine with me, if I can make this a one-shot generation, which is not part of the build-deploy process. > Another question how to generate jOOQ classes during build process. > Unfortunately we have keep classes, generated by jOOQ , on source control at > this moment. We already discussed before that we need two phase generation. > One phase - database introspection, the result (mediated database model) can > be kept on source control (in xml format, for example), run manually, on > demand. > The second phase - generation code from model during build process. Yes, we had discussed this. It is still on the road map, but hasn't been a priority so far. The favoured solution is -as you put it- to use jooq-meta/jooq-codegen to generate XML output from the schema instead of Java output. Then to use jooq-meta/jooq-codegen again, to use the XML input rather than a database and generate the Java output from there. Any contributions would be very welcome, most importantly an XSD defining the XML file. I had raised the question on Stack Overflow, without success so far: http://stackoverflow.com/questions/8184849/is-there-a-sql-information-schema-xsd-definition Cheers Lukas 2012/4/10 Sergey Epik <[email protected]>: > Hello Lukas, > > On Tue, Apr 10, 2012 at 10:35 AM, Lukas Eder <[email protected]> wrote: >> >> Hello Sergey, >> >> Some more feedback to your questions: >> >> > 2. In order to generate classes from xsd we suggest: >> > >> > add the following section to jooq-trunk\jOOQ\pom.xml (after >> > <build><plugins>): >> >> What are the immediate advantages of using Maven for XJC source code >> generation? I'd like the complete source to be checked in in SVN >> without requiring users to use Maven for building. Can this still be >> done? > > > It's a good practice. It simplifies configuration, generated source code is > always up to date, nobody can change it and commit. > You do not have keep jar files on source control, etc. > Modern IDE's understand maven life cycle and include generated source code > to classpath, so I do not see any problem here. > > Another question how to generate jOOQ classes during build process. > Unfortunately we have keep classes, generated by jOOQ , on source control at > this moment. We already discussed before that we need two phase generation. > One phase - database introspection, the result (mediated database model) can > be kept on source control (in xml format, for example), run manually, on > demand. > The second phase - generation code from model during build process. > >> In the meantime, use this: >> >> Factory.field("current_timestamp", SQLDataType.TIMESTAMP); >> >> If you look at CURRENT_TIMESTAMP as being a language-construct, I >> think the reason why you cannot set the precision the way you wanted >> is that this construct accepts no bind values. The correct way to do >> it is this: >> >> Factory.function("current_timestamp", SQLDataType.TIMESTAMP, >> Factory.literal(6)); > > > Thank you, it works! > > -- > Best regards, > Sergey Epik
