On Monday, May 8, 2017 at 4:41:04 AM UTC-4, Lukas Eder wrote: > > Thanks for sharing, Adam. That's a very interesting approach, so the > generation is always "all or nothing" and it won't allow for incremental > builds, right? > > Yes that is mostly correct. We don't import the jooq code generation modules (ie the maven modules that run the generator). Instead developers run `mvn install` for the jooq module and let Eclipse/IntelliJ just delegate to their respective maven plugins for the rest of the imported modules. IIRC both IDEs are smart enough to pick up the SNAPSHOT locally installed jar.
To enable looking at the code we also attach sources. Both IntelliJ and Eclipse are pretty smart about finding the source as well with their maven plugins. People crap on Maven but the IDE integration is incredibly good for all three major IDEs. If you are running the generator and attaching sources (ie generating a source jar) you will want to do: http://stackoverflow.com/questions/4253700/maven-phase-executing-twice Otherwise the generator will run twice. > If incremental builds are desired (e.g. a database change involves only > 1-2 columns that need regeneration), then, perhaps the catalog / schema > version provider SPI could be useful, instead: > > https://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced/codegen-config-version-providers > > <https://www.google.com/url?q=https%3A%2F%2Fwww.jooq.org%2Fdoc%2Flatest%2Fmanual%2Fcode-generation%2Fcodegen-advanced%2Fcodegen-config-version-providers&sa=D&sntz=1&usg=AFQjCNGoOZbDrdX1rDPrSpf1PSEwnpv5_g> > > This works very well with Flyway, where the schema version provider can > look up the schema version in the Flyway migration table and prevent a > re-generation if the version hasn't changed. > > That is a very interesting SPI. I'll have to take a look at that but currently many of our projects are stuck on JDK 7 (thus we are on 3.6 ... I'm embarrassed to go into the detail of why that is). I presume Axel knows about this SPI? Hope this helps, > Lukas > > 2017-05-06 20:29 GMT+02:00 Adam Gent <[email protected] <javascript:>>: > >> Hi all, >> >> A tip for those using Maven that use the code generation plugin is to put >> the plugin in its own profile and have it only activate >> when the generated-sources directory is missing. >> >> <profile> >> <id>jooq</id> >> <activation> >> <!-- trick to disable constant jooq generation --> >> <file> >> <missing>${basedir}/target/generated-sources</missing> >> </file> >> </activation> >> <build> >> <plugins> >> <!-- flyway plugin --> >> <!-- jooq plugin --> >> </plugins> >> </build> >> </profile> >> >> Now I realize not everyone generates the classes on every build and might >> prefer checking in the classes but we like to generate the classes after >> running the flyway migration scripts. >> >> The only caveat now is that developers must run a "mvn clean" if they >> want to rerun the code generation which typically happens anyway when a >> developer pulls. It also will always happen on the build machine since the >> build machine starts from scratch anyway. >> >> The way we roughly structure our maven projects is to alway have a >> multimodule project. Then we make a jooq module that only has the flyway >> plugin and migration scripts and the jooq code generator plugin. No other >> code. Then other modules depend on the jooq module. This works pretty well. >> >> -- >> 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.
