-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve DevEx for event handlers #719
Comments
Looking at the sources, I see that a Lines 722 to 724 in df32dd8
IMO an explicit scope would both make it clearer for consumers, and remove the need for that snippet. |
I don't know. My personal opinion on this is that the IDE is incorrect and I'm not sure I want to change things to comply with IDE requirements. You can add the I'm not sure how moving the annotations to the method helps? |
The problem here is how can an IDE know that the class becomes part of Quarkus DI, when there are no markers to make it obvious?
This is probably more of a style opinion, but it is also based on what IDEs offer. Most annotations in Quarkus, Spring, Micronaut (etc.), are applied to methods instead of parameters. Plus, in IntelliJ IDEA method annotations can be used to forcefully suppress unused warnings. |
I'm not sure I understand "streamlining it"? It would make things harder for other people. You can simply add the annotation yourself if that's what you prefer and all is fine.
Well, I would say the annotations are supposed to target what's the target. In this case, there's a clear link between the event and the injected payload. Maybe we could support both and have an error if we have annotations in both places. I definitely don't want to break existing applications :). I think it would require quite a few changes. Would you be willing to have a look at it? |
Oh, also, thanks for the feedback. I'm definitely not discarding it, let's have an open discussion. |
I just mean allowing doing it in a single way after a deprecation period, when you'll switch to 3.x. Correct me if I'm wrong, but you also do some magic with
Yup that's what I was thinking about. Adding a new target to the annotations, and adjust the extension's processor.
I can have a look, maybe next weekend! I guess most changes will be in |
Maybe I need to be clearer on the intention here. For me, you don't need a scope because you don't even need to care about CDI. From these classes, we generate extra classes which will be CDI beans and wire everything (including the The thing is I don't really want people to care about CDI or require they understand all the wiring. I can understand how it may feel a bit too magic when you actually are used to CDI.
Yes, exactly. We definitely need to make sure we raise an error if we have annotations on both methods and parameters. |
I find myself in a situation where creating a class to handle GitHub events results in multiple inspection warnings in IntelliJ IDEA.
Take for example this screenshot:
This works perfectly. Quarkus wires up
PullRequestMilestoneCheck
and injects the constructor dependencies, and this GitHub extension does its job.However, the class and all its methods are marked as unused, there is no IDE navigation to the injected beans, and it is unclear which bean scope the extension assigns to the class.
This could be improved by:
@Singleton
or@ApplicationScoped
. Transitively avoids an explicitopen
.The text was updated successfully, but these errors were encountered: