Hi Denis, Thanks for your explanations. While I appreciate the fact that your approach seems more convenient, I'm still not quite sure why these a multi-project setup is a show stopper for you. "Works better" is rather subjective and perhaps you ran into bugs in other tools that you're now trying to work around, but frankly, none of those tools (neither IDEs nor Spring Boot, nor jHipster) should be opinionated about how many projects / modules any particular software is split up into.
I mean, in pretty much every application I ever worked on, we wrote our own libraries that we made generally available to many other systems, so a single project setup was simply never something we would have wanted anyway. Now, this doesn't mean I don't agree we should find a solution to this problem, I just really don't think that the arguments are strong ones in favour of prioritising the improvement. The problem with the APT based approach and the current JPADatabase in jOOQ is the fact that APT based approaches do not expose the java.lang.Class / java.lang.reflect.* based introspection API, which is needed by JPADatabase in order to work with org.hibernate.boot.MetadataSources programmatically behind the scenes. The APT javax.annotation.processing.Processor works with an alternative reflection API that cannot be used in the same way as the above. This means that either we can work out a solution involving calling some Hibernate (or any other JPA ORM) internals, which already uses the APT Processor API, or we roll a lot of functionality our own (which certainly cannot be prioritised), or maybe there's another solution that I'm missing right now. I think the best way to push this feature would be to hint at a solution that I might be missing, which doesn't involve re-implementing pretty much a complete JPA annotation processor. I hope this helps, Lukas 2017-12-26 9:56 GMT+01:00 Denis Miorandi <[email protected]>: > Hi Lukas, there are a couple of reasons why I can't split my project. The > most importants are: > > - jHipster generate code in a single project. I'm using generator non > only to generate one-shot initial project but also to maintain > project. Tasks like add or remove fields to entity are accomplished > via jHipster generator. This is a very productive way to work cause > generator > update all neccessary stuffs automatically. Btw this work just if i > don't move files into another projects > - IDE generally works better with single project > - Tools to automatic redeploy on dev side (like spring-boot-dev-tools) > works better with single project > > I would like also add a consideration based on my experience. I'm coming > from a bounch of projects developed as fragmented projects (following maven > guidelines), > but actually I came back to single project mode cause my productivity was > not optimal due to fragmentation(so IDE, spring-boot-dev-tools, deployment, > ....) > This is why I'm agree with jHipster single project mode. > > > Denis > > > > > Il giorno giovedì 21 dicembre 2017 13:23:01 UTC+1, Lukas Eder ha scritto: >> >> (I cannot split into more jars, long story...)` >> >> >> Can you explain why you cannot create more than one project in your >> development environment? I'm interested in that "long story". >> >> 2017-12-21 13:14 GMT+01:00 Denis Miorandi <[email protected]>: >> >>> Ok. So whats informations more do you Need from me? >>> >>> Il 21 dic 2017 11:47 AM, "Lukas Eder" <[email protected]> ha scritto: >>> >>>> Before we prioritise, I'd like to really really understand why you have >>>> this limitation :) >>>> >>>> 2017-12-21 11:44 GMT+01:00 Denis Miorandi <[email protected]>: >>>> >>>>> tks Lukas for issue, my limitation it's at development time. >>>>> About priority. Probably there are a lot of people that work in hybrid >>>>> jpa+jooq scenario, I suppose, but I don't know. This is at you. To me this >>>>> feature have a great value, cause >>>>> I'm going to develop a lot of projects using great jhipster code >>>>> generator (spring-jpa+angular). >>>>> >>>>> Thanks >>>>> Denis >>>>> >>>>> >>>>> >>>>> Il giorno giovedì 21 dicembre 2017 11:28:15 UTC+1, Lukas Eder ha >>>>> scritto: >>>>>> >>>>>> Hi Denis, >>>>>> >>>>>> 2017-12-21 11:12 GMT+01:00 Denis Miorandi <[email protected]>: >>>>>>> >>>>>>> (I cannot split into more jars, long story...) >>>>>>> >>>>>> >>>>>> Does that limitation apply to your development set up, or only to >>>>>> your runtime environment? In the latter case, you could use e.g. the >>>>>> Maven >>>>>> assembly:single command to put everything in a single jar: >>>>>> https://maven.apache.org/plugins/maven-assembly-plugin/singl >>>>>> e-mojo.html >>>>>> >>>>>> Or the Maven shade plugin: >>>>>> https://maven.apache.org/plugins/maven-shade-plugin/ >>>>>> >>>>>> >>>>>>> It's a big limitation that jooq requires compiled classes to >>>>>>> generate it's own objects (to make it work I can't generate jooq from >>>>>>> jpa, >>>>>>> but I've got to do it via db directly, but I've got a lot of issue about >>>>>>> this, like circular dependency issue,...) >>>>>>> >>>>>> >>>>>> Hmm, that's really a class loading issue, not strictly related to >>>>>> jOOQ. Perhaps, the JPADatabase could use in-memory compilation for those >>>>>> entities, but that would be rather difficult to get right in more complex >>>>>> project setups, where the entities have external dependencies. >>>>>> >>>>>> >>>>>>> I'm wondering if jooq-jpa entities generator could be an apt one, >>>>>>> like others i.e. querydsl-jpa, JPAMetaModelEntityProcessor. These ones >>>>>>> are >>>>>>> perfectly integrated in my scenario. >>>>>>> >>>>>>> What do you think about it? Are there some impedements I cant' see >>>>>>> about it? >>>>>>> >>>>>> >>>>>> It's a matter of priorities and a question whether the can of worms >>>>>> called APT should be opened. Perhaps it can be done, indeed. I've >>>>>> created a >>>>>> feature request for this: >>>>>> https://github.com/jOOQ/jOOQ/issues/6945 >>>>>> >>>>>> Thanks, >>>>>> Lukas >>>>>> >>>>> -- >>>>> 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 a topic in the >>>> Google Groups "jOOQ User Group" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>>> pic/jooq-user/y4Xd4mzJtUQ/unsubscribe. >>>> To unsubscribe from this group and all its topics, 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]. >>> 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. > -- 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.
