First off I'm making no claims to have done all the work you have already done, but I'm involved in a project where the final aim will be to do the CI cycle that you describe and post the resulting JOOQ output into a Maven repository.
The logic being that the schema will be coded in Liquibase or Flyway and have its own unit test cycle, with the output being a JOOQ library that can then be consumed by developers. >From my point of view this looks like a nice R&D project with the value add of a fully tested schema and JOOQ library that can be by developers. Just to complicate things I also plan to use Gradle rather than Maven as Maven XML does my head in :( and Gradle may remove this problem. On Saturday, April 12, 2014 10:07:44 PM UTC+1, Witold Szczerba wrote: > > In my previous project I was thinking about this and finally I have > came to conclusion that the best option is to let CI server access a > real database to build project. My build was prepared for a database > details to be provided easily, so CI builds had theirs own databases > (in fact two, one for deployment and one for integration tests). > > So, the database part of build system worked like this: > 1) destroy databases (let's call them DEV and DEV_TEST) > 2) build database module, this is: > a) Liquibase, as part of mvn build, recreates databases from scratch, > b) JOOQ, as later part of mvn build, generates code, > c) mvn compiles everything, > d) mvn install > 3) compile, run integration tests (using DEV_TEST), > 4) deploy to JEE server, > 5) run e2e tests. > > Staging builds are almost the same, but they do not destroy the > database, Liquibase just upgrades schema to new version. > > At the beginning I was not sure if this is OK to couple the project > building process to a running database, but it really worked well. > Every developer had it's own database (either locally, in virtual > machine or an account on our development server). What's important > here is that developers didn't have to build database module on each > code change, but only when they actually altered the schema. It was > separated from a web application maven project. Building it did not > take long though, I don't remember, but I think it was something like > less than 2 minutes. > > I was thinking: what's wrong with this? And finally came to conclusion > that there is absolutely nothing wrong with this. In fact, it is even > better, because everyone, from developers, CI DEV builds to CI STAGING > and PRODUCTION builds work on the same database engine. There is no > excessive abstraction above database between Liquibase and JOOQ: > what's in there is what gets used to generate schema and it's what > gets used to run integration and e2e tests. I liked it. > > You might think that tying building process to > > Regards, > Witold Szczerba > > 2014-04-12 22:23 GMT+02:00 Mohit Jaggi <[email protected] <javascript:>>: > > >> > >> > >> Already today, you can implement your own jOOQ-Meta Database that > supplies > >> schemas, tables, columns, etc. to the code generator. This custom > Database > >> could read any sort of XML file, e.g. an external one by Flywaydb or > >> Hibernate. > >> > >> How you generate that external file would then be entirely up to you. > >> > >> > > Lukas, > > I did not understand. Could you please point me to an example or section > of > > jooq documentation please? > > > > Rob, > > For the time being I am adding generated code to git repo, which I don't > > like much. > > > > Thanks, > > Mohit. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "jOOQ User Group" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
