I can't recall why but I had some issue with GeneratorStrategy.getFile and the way I did it just turned out easier (for me).
The reason why the separation is nice because you can use the generated POJO for an internal API (aka microservices with a message bus). This works particularly well since our services are protocol driven (that is the message aka POJO is the contract and not endpoints like REST/SOAP). Consequently I make a maven submodule (or top level project) that has generates the POJO and jOOQ specific stuff. Because I can't separate the classes out I make jOOQ as an optional dependency. It is not ideal because the generated jOOQ specific classes (Record, Table etc) crowds the name space but at least the compiler catches this (if your not using jOOQ in the client which we often are...). This is why I make sure to append "Table" to the generated Table classes because it is very easy to accidental import them. In the future we may just manage our POJOs independently and rely on MapStruct (http://mapstruct.org/ like ModelMapper but generated code). But then we are copying two times (Our POJO -> jOOQ POJO -> jOOQ Record). Not ideal but probably inconsequential to performance. -Adam On Thursday, September 1, 2016 at 3:15:44 AM UTC-4, Lukas Eder wrote: > > Hi Adam, > > These are interesting thoughts, thanks for sharing. In principle, you > could override the GeneratorStrategy.getFile() methods to relocate the > POJOs into a different .jar file. The method hasn't been designed for this > purpose, so there might be 1-2 caveats, but in principle, that might be one > other possible hack to do so. > > Hope this helps, > Lukas > > 2016-08-31 18:28 GMT+02:00 Adam Gent <[email protected] <javascript:>>: > >> Call me an old school Java developer but I like layers of separation. >> I like the generated POJO classes to be decoupled as possible and they >> fairly are but... >> >> The current code generator will do several things I don't like. >> >> 1. Make POJO classes with the exact same name as the Table objects. >> 2. I don't like having POJO in the package name. We use package names for >> all kinds of things (routing, metrics) so it is ugly to see pojo. >> 3. Mix the POJO classes in the same hierarchy as the Table / Record >> classes. >> 4. If using the Maven generator all of the above will be in the same Jar >> (ideally the pojos would be in their own jar). >> >> Thus I have written a code generator that will put all the POJOs into a >> data package and everything else will go into an internal package. >> >> com.mycompany.data <--- pojos live here >> com.mycompany.internal <-- database tables (the subpackages are the same). >> >> https://gist.github.com/agentgt/221f76b5d3ed49272ef467c0e2143069 >> >> Sadly I haven't figured out an effective way to separate the classes into >> separate Jars easily with out rerunning the generator and doing some maven >> hacks. >> >> However there are ways to exclude package names (ie ban other maven >> modules from using *.internal): >> >> >> http://stackoverflow.com/questions/7467756/maven-plugin-to-restrict-specific-packages-from-being-used >> >> -- >> 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.
