jooq jpa generator based on Annotation Processor Tool?

[Denis Miorandi]

Hi Lukas,

My project is like this:

• spring-jpa (hibernate project)
• code-first one, database is maintained via liquibase
  
• jooq used on some complex tasks
• single project (I cannot split into more jars, long story...)

Actually is very tricky to me to generate jooq objects, cause I can't move domain objects in a sepate jar. 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,...)

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?

Tks

Denis

[Lukas Eder]

Hi Denis,

2017-12-21 11:12 GMT+01:00 Denis Miorandi <denis.m...@gmail.com>:

(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/single-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

[Denis Miorandi]

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

[Lukas Eder]

Before we prioritise, I'd like to really really understand why you have this limitation :)

--

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 jooq-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Denis Miorandi]

Ok. So whats informations more do you Need from me?

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/topic/jooq-user/y4Xd4mzJtUQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+unsubscribe@googlegroups.com.

[Lukas Eder]

(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".

[Denis Miorandi]

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

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.

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/topic/jooq-user/y4Xd4mzJtUQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.

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 jooq-user+...@googlegroups.com.

[Lukas Eder]

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

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.

[Denis Miorandi]

Hi Lukas, tks for your honest answer about priority. I really appreciate it. 

I would like to examine in depth apt generation to have obtain new hints about this I'll eventually wrote it in github issue.

Tks

Denis

[Lukas Eder]

2018-01-02 16:22 GMT+01:00 Denis Miorandi <denis.m...@gmail.com>:

Hi Lukas, tks for your honest answer about priority. I really appreciate it. 

I would like to examine in depth apt generation to have obtain new hints about this I'll eventually wrote it in github issue.

Cool, thank you very much for your help!

Lukas 

[Lukas Eder]

At the recent JAX conference, I had an interesting discussion with Peter Verhas, another speaker. In principle, it would be possible to generate jOOQ classes during the Maven test phase, assuming that phase will never be skipped. At that point, all the ordinary classes are already available, and jOOQ's JPADatabase could be introspecting them using the existing mechanisms. The jOOQ generated code would obviously end up in the test target directory, and would have to be included in the ordinary jar file using some workaround.

This is a hack, but perhaps one that works sufficiently well.

Lukas

[Denis Miorandi]

Hi Lukas,

If I right understood , I don't think this is a solution cause test phase run after compile but compile require code generation to complete.

The point is that what you call "ordinary classes" depends on jooq generated table and can't compile without generation.

Denis

--

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/topic/jooq-user/y4Xd4mzJtUQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/a0485350-01d6-4435-9b79-c0af87cea3ac%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Dott. Denis Miorandi
via dei Vignai 27
38060 - Nogaredo (TN)