Hi Sergey, >> 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 going to try your suggested solution. I'll be looking for the right way to put generated sources in version control, but in general it probably makes sense to move source code generation from ant to Maven. Thanks for your contribution! Cheers Lukas 2012/4/10 Lukas Eder <[email protected]>: > 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
