Thinking that the long term solution for JOOQ is to get out of the business of trying to emulate database languages. perhaps something like this would have been a solution:
https://github.com/opentable/otj-pg-embedded/blob/master/README.md On Wednesday, April 3, 2019 at 3:19:27 PM UTC-4, sdwarwick wrote: > > This has proven to be far more difficult than I realized, particularly > since the application is very large and there is no appetite for > restructuring, creating multiple modules or modifying existing classes. > > Notes: > > 1. The strategy to use @entity scanning was driven by the need to 1) > keep database userIds and passwords out of maven and Intellij > configuration > files - they are only set at the environment level in production and 2) > ensure that JOOQ tracks the class entity structures, not the status of the > database. > 2. Entity classes are not always pure data - they sometimes have > references to service classes. In fact, some are even Autowired using > Aspectj and @configurable. > 3. Generate-sources requires the compiled version of the Entity > classes. > 4. Compiling an Entity class triggers the compiling of any dependent > classes (maven-compiler-plugin) > 5. "maven clean package" should work. > 6. The ultimate desire was to have the same level of fluidity we get > from JPA / hibernate / lombok , where generated sources and annotations > are processed in real time during editing and are essentially invisible. > Right now, modifying an entity class doesn't require any special > processing > in the IDE and even can be done during debugging with JRebel integrated > into Intellij > > Findings > > 1. setting up multiple modules is not possible due to the entity > interdependence issues, among other things. > 2. the "naive" approach of simply adding a generated-sources execution > phase clearly doesn't work since the compiled entity classes aren't there > yet and JOOQ doesn't generate anything > 3. trying to compile all of the sources first, and then running the > JOOQ class generator afterward doesn't work, since some of the application > classes refer to the JOOQ generated classes, which don't exist. The > compile phase fails and the needed entity classes are never generated. > 4. trying to add a compile step during the generate-sources phase just > for the entities. This doesn't work since there is a bug with the > maven-compiler-plugin that causes dependent classes to be compiled without > the annotation processors (lombok) active. > > Conclusion - the current structure of JOOQ makes integration with existing > JPA / hibernate applications quite difficult. Not sure how to proceed. > > > > -- 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.
