On Monday, May 8, 2017 at 10:48:32 PM UTC-4, Samir Faci wrote: > > Is there any particular reason you don't want the generate code as an > independent library? > > We consume a jar file that we can flip between a snapshot or released > pinned version depending on the user case. It works fairly well. > > Our DB versioning is somewhat home grown, but it's similar to flyaway's > model. > > Yes we do this as well and often has some big advantages in that it makes importing the projects into Eclipse/Intellij easier.
The reason we don't all the time is that we already have 30 or so independent projects (various reasons why this is but mostly microservice reasons). The maven release plugin is not awful but its not that good so keeping multiple projects that are basically coupled in sync is annoying even using the maven versions plugin (that plugin is basically broken btw) and the corresponding constant merging of pom files. Thus it has becomes increasingly painful to have to independent maven projects even with a super parent (ie all the independents use a common parent) and even with vast improvements of jenkins (configuration drift is a pain). We even have our own custom maven plugins as well as build tools to do cascading releases (again this is an issue because of having tons of independent project). I have been meaning some day to release our build tools to the wild (which essentially are just a better maven release plugin process). So I have mixed feelings on the independent project approach. > > > On Mon, May 8, 2017 at 12:02 PM, Adam Gent <[email protected] > <javascript:>> wrote: > >> >> >> 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]>: >>> >>>> 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]. >>>> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Thank you > Samir Faci > https://keybase.io/csgeek > -- 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.
