JPA Static Metamodel Generator

[DavideD]

JPA defines a typesafe Criteria API which allows Criteria queries to be constructed in a strongly-typed manner, utilizing so called static metamodel classes. For developers it is important that the task of the metamodel generation can be automated.

Hibernate provides an annotation processor that generates the classes automatically.
This usually requires adding a dependency to the project and/or configure the build tool.

Would it be possible for Quarkus to generate the metamodel everytime Hibernate ORM is on the classpath?

Hibernate 5.6 JPA static metamodel generator documentation

Hibernate 6.1 JPA static metamodel generator documentation

[quarkus-bot]

/cc @Sanne, @gavinking, @gsmet, @mswatosh, @yrodiere

[pipinet]

good idea! we also need this feature！
preferably panache can support typed Criteria API

[famod]

Are we talking about the generate-code goal of quarkus-maven-plugin (gradle respectively)?

I suppose in multi-module projects in which you might have a persistence module (=not where the actual quarkus app is built) you are either out of luck or you have to add the plugin but just with the generate-code goal?

[pipinet]

@famod
hope to support single/multiple module both!😄

[DavideD]

I suppose in multi-module projects in which you might have a persistence module (=not where the actual quarkus app is built) you are either out of luck or you have to add the plugin but just with the generate-code goal?

Not sure I understand what you mean, but if one of the modules doesn't use Quarkus, they can add the required dependency on the classpath.

But if the entities are on the classpath of the Quarkus app, there should be a way to see them and generate the metamodel classes

[famod]

My point is when to generate the classes. If you have a persistence module then chances are you have some repo/dao/service code in there that wants to use the generated metamodel classes.
Since there is no quarkus-maven-plugin execution in such modules (normally, at least), no metamodel classes would be generated for/on the classpath of that module.

[agreedSkiing]

So how compatible is the hibernate jpamodelgen dependency with quarkus 2.16.4.Final currently?

[yrodiere]

So how compatible is the hibernate jpamodelgen dependency with quarkus 2.16.4.Final currently?

As far as I can tell it should work? This issue is not about making it work, it's about having Quarkus generate the static metamodel instead of forcing you to use a separate maven plugin.

[famod]

@Sanne, continuing from #32615:

@Sanne while this is certainly a good idea for smaller projects/services, I don't think it works that well when you have multiple modules and the quarkus app is not built in the module that contains the entities (or better to say "users" of the metamodel classes). So I'm not sure that approach can cover all cases.

Good point - it might need some flexibility, perhaps some options to control the output directory. But I suspect doing it OOB would help most people, and for most other people I'd expect that if entities are provided by an external jar, for it to contain the metamodel as well?

Let's continue on #29068

But I suspect doing it OOB would help most people

Yes, agreed!

and for most other people I'd expect that if entities are provided by an external jar, for it to contain the metamodel as well?

I can't speak for all those users, but for me such an entity (or "persistence") module is usually not external; it's usually a module in my main repo.

[FroMage]

I think I can get it done in #36168 using a variant of CodeGen, but I fear this will prevent IDEs from running APT automatically, which is not a problem for IJ which does not run it (as far as I'm aware), but is a problem with Eclipse, which does.

I wonder if @fbricon @sbouchet or @angelozerr can answer this question:

If we make one APT plugin run automatically (via the quarkus-maven-plugin and the presence of the quarkus-hibernate-orm extension), can we rely on the Quarkus Tools IDE plugins to instruct the IDE that it has to run that APT plugin? Since it won't be defined explicitely anymore.

[fbricon]

In eclipse/vscode-java land, m2e now automatically runs all plugins by default (not that I agree with that decision). So it might just work. Or not.

Annotation processors in the classpath or defined in the maven-compiler-plugin config (or some supported annotation plugin) would get automatically invoked on each incremental build. It generally works well.
It might work for quarkus-maven-plugin too, but potentially with a large performance hit, since quarkus-maven-plugin does a lot of things and I don't know if it's incremental-build friendly (unlikely). See https://wiki.eclipse.org/M2E_compatible_maven_plugins#BuildContext

[FroMage]

Uh, I have no observed that Eclipse ran plugins such as quarkus-maven-plugin by default (my version: 2023-06 (4.28.0)), and yeah, it does not do incremental builds. What's worse is how it combines with quarkus:dev running.

Normally, I can rely on Eclipse incremental compilation (and APT) and it doesn't get in the way of quarkus:dev, but if suddenly quarkus-maven-plugin runs in parallel to quarkus:dev that will surely cause issues…

[FroMage]

If we make one APT plugin run automatically (via the quarkus-maven-plugin and the presence of the quarkus-hibernate-orm extension), can we rely on the Quarkus Tools IDE plugins to instruct the IDE that it has to run that APT plugin? Since it won't be defined explicitely anymore.

Note that in 806bf2d we already automatically ran one APT processor for all Gradle builds, so there's precedent.

[yrodiere]

Hey @pipinet. Once again: please open a GitHub Discussion instead of hijacking an existing issue: it's bad form.