Fix vertx-mutiny-generator and vertx-codegen leaking to runtime#1316
Fix vertx-mutiny-generator and vertx-codegen leaking to runtime#1316jponge merged 1 commit intosmallrye:3.xfrom
Conversation
gsmet
changed the title
|
BTW, to clarify: my point is to avoid having |
jponge
left a comment
jponge
left a comment
There was a problem hiding this comment.
Thanks
The vertx-codegen annotations are used for code generation purpose and mark asynchronous interfaces / methods.
AFAIK they have no runtime use (@tsegismont am I missing any case?) so the dependency can indeed be made optional.
This is something that has apparently been fixed in main already but given Quarkus 3.x is far from being EOL, I think we should fix it in 3.x too. I went with the approach of making the dependency optional and having it a dependency of the processor. We need the dependency around because of the @fluent marker annotation. My question about this annotation: is it actually used by anything at runtime? It doesn't seem so but I wasn't able to fully rule it out, thus why I am asking. Note that we also have a @fluent in Quarkus: TransactionalContextConnection in the Hibernate Reactive extension. This will require a fix.
|
We're rolling-back most of this because it breaks compilation in many Quarkus extensions (Redis, etc). |
|
I’d like to have a look. Maybe we should just add a dependency? do you have a pointer? |
|
Yes you can see the first run in quarkusio/quarkus#53875 that failed on a few classes that required Vert.x annotations ( As a quick fix we marked the dependencies as non-optional with @anavarr, which effectively reverted the transitive dependency behavior, we could have removed all declarations as well. What we could do is:
|
|
I'm going to make it optional again in a 3.22.2, and I'll fix the related Quarkus modules. They shouldn't use annotations in most (even all) cases. |
|
Actually @anavarr is going to do it 😄 |
|
@jponge also, if they use annotations, you can just add the artifact containing the annotations as an optional dependency there. It's much better than having everything depending on a codegen artifact. |
|
Well most of these annotations have been put for no reason, so better drop these. |
|
We've been delayed with 3.22.2 due to Maven Central being slow today, we'll finish next week. |
2 participants
This is something that has apparently been fixed in main already but given Quarkus 3.x is far from being EOL, I think we should fix it in 3.x too.
I went with the approach of making the dependency optional and having it a dependency of the processor.
We need the dependency around because of the
@Fluentmarker annotation.My question about this annotation: is it actually used by anything at runtime? It doesn't seem so but I wasn't able to fully rule it out, thus why I am asking.
Note that we also have a
@Fluentin Quarkus:TransactionalContextConnection in the Hibernate Reactive extension. This will require a fix.
CI seems to be happy about it so that's a good first step.