3.0 Update process does not update hibernate-jpamodelgen annotation processor

[famod]

Describe the bug

Not sure this is out of scope for the update goal/process, but I couldn't find anything in the migration guide.

Running mvn io.quarkus:quarkus-maven-plugin:3.0.0.Final:update -N -Dstream=3.0 leaves hibernate-jpamodelgen annotation processor untouched (if present), resulting in uncompilable metamodel classes with javax imports.

In my case the processor is simply added as a depedency to maven-compiler-plugin (together with other processors).

Expected behavior

Metamodel classes using jakarta imports

Actual behavior

Metamodel classes using javax imports -> compile errors

How to Reproduce?

None, ATM.

Output of uname -a or ver

No response

Output of java -version

17.0.6

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.6 -> 3.0.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Maven 3.8.8

Additional information

No response

[quarkus-bot[bot]]

/cc @Sanne (hibernate-orm), @gsmet (hibernate-orm), @yrodiere (hibernate-orm)

[gsmet]

I’m not sure we can do something about it but if you attach a sample project, I can have a look.

[famod]

No sure it's worth the effort. Adding something to the migration guide is probably enough?

Btw, for each and every update of Quarkus I'm going through several dependency and plugin versions in my project, comparing them to what has changes in Quarkus BOM:

• hibernate-orm.version -> hibernate-jpamodelgen
• jacoco.version -> jacoco-maven-plugin
• jandex.version -> jandex-maven-plugin

So, such potential issues are not entirely new to me, but it would be great to have more tooling support for that (in general, not just for major upgrades like 3.0).

[gsmet]

I think it's worth it if doable.

[gsmet]

If you can put together an example with all of them, I'll see if we can do something. IIRC the plugin update facilities in OpenRewrite are scarce but we could work on improving that.

[Sanne]

Regarding hibernate-jpamodelgen, we should automate the generation, so that you don't have to enable the plugin and that it works better with live-reload capabilities. I think we had an issue already for it, just never got to do it.

[famod]

@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.

[famod]

If you can put together an example with all of them, I'll see if we can do something. IIRC the plugin update facilities in OpenRewrite are scarce but we could work on improving that.

I'll see what I can do. I'm still kind of blocked by https://github.com/openrewrite/rewrite/issues/3022#issuecomment-1505421339, but locally I can replace the versions with something static for now.

[gsmet]

I think updating a plugin dependency will be a problem. You can rewrite the dependencies but you cannot update one dependency in particular. It wouldn't be that hard to add it to OpenRewrite though.

[Sanne]

@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 https://github.com/quarkusio/quarkus/issues/29068

[famod]

FWIW, I think this has become mostly obsolete, given that the latest maven-compiler-plugin version applies dependencyManagement to annotationProcessorPaths and jpamodelgen is defined already in the Quarkus BOM.

Even ECJ should play along nicely after https://github.com/codehaus-plexus/plexus-compiler/pull/350 is released.

People still using the compiler-plugin dependencies to define annotation processors are still affected, though.

[yrodiere]

Thanks for following up.

People still using the compiler-plugin dependencies to define annotation processors are still affected, though.

Right, but these people will be out of luck once they upgrade to Quarkus 3.7+/ORM 6.4+ since jpamodelgen now has mandatory dependencies and thus will fail when registered that way.

The right way to use jpamodelgen (regardless of your version of Quarkus) is to use maven-compiler-plugin 3.12.1+ and annotationProcessorPaths; see https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.7#static-metamodel-annotation-processor-hibernate-jpamodelgen-can-no-longer-be-used-as-a-provided-dependency.

I'll tentatively close this in favor of #37477, but let me know if this needs to be reopened.