I sort of mentioned it earlier but wasn't clear. I think you can generate without the POJOs but you can't generate the POJOs without the Table/Record classes. I will have to check on this though.
The way I think I had tried with the Maven hacks is to run the generator twice, once in each maven submodule and then using my naming scheme remove the package named "com.mycompany.db.internal" with the Jar plugin (or maybe it was the assembly plugin... I can't recall). To be clear and honest though I don't think it is worthwhile changing jOOQ for this behavior. I brought it up as a talking point and to maybe see what others are doing. I think the better solution is for folks to make their own domain objects by initially opening up the generated POJOs and copying/pasting the contents to a new class and then using MapStruct to map their POJO to jOOQ's POJO. MapStruct will even check if you missed fields. Yeah you have to run code generators but such is the life of Java. Generated code is highly underrated compared to metaprogramming (ruby) are extreme type magic (scala). On Friday, September 2, 2016 at 4:45:15 AM UTC-4, Lukas Eder wrote: > > Interesting, thank you for the additional insight. > > I'm not sure if I caught this correctly, but have you also tried running > the code generator twice? Once without POJOs and once with POJOs only? > > 2016-09-01 23:23 GMT+02:00 Adam Gent <[email protected] <javascript:>>: > >> 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]>: >>> >>>> 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]. >>>> 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. >> > > -- 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.
