-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Make Picocli version providers unremovable classes #38083
Conversation
geoand
commented
Jan 8, 2024
•
edited
Loading
edited
- Closes: picocli should be able to mark its annotation dependent classes as unremovable #38077
This comment has been minimized.
This comment has been minimized.
extensions/picocli/deployment/src/main/java/io/quarkus/picocli/deployment/PicocliProcessor.java
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
related to #38077 |
extensions/picocli/deployment/src/main/java/io/quarkus/picocli/deployment/PicocliProcessor.java
Outdated
Show resolved
Hide resolved
extensions/picocli/deployment/src/main/java/io/quarkus/picocli/deployment/PicocliProcessor.java
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
✔️ The latest workflow run for the pull request has completed successfully. It should be safe to merge provided you have a look at the other checks in the summary. You can consult the Develocity build scans. |
@@ -99,6 +101,17 @@ void picocliRunner(ApplicationIndexBuildItem applicationIndex, | |||
additionalBean.produce(AdditionalBeanBuildItem.unremovableOf(DefaultPicocliCommandLineFactory.class)); | |||
quarkusApplicationClass.produce(new QuarkusApplicationClassBuildItem(PicocliRunner.class)); | |||
} | |||
|
|||
// Make all classes that can be instantiated by IFactory unremovable | |||
unremovableBean.produce(UnremovableBeanBuildItem.beanTypes(CommandLine.ITypeConverter.class, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok - so this is doing it for all instances even if not referenced by picocli config.
Just curious why you do it this way when we only have to do it for those pointed to by users annotation?
Ease of coding in quarkus or that you don't believe it will matter enough in extra memory used ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok - so this is doing it for all instances even if not referenced by picocli config.
All it does it make beans of this type unremovable - nothing more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious why you do it this way when we only have to do it for those pointed to by users annotation?
This way is much much cleaner and also makes chances of copy-paste errors in the code far lower.
This makes the IDE warn extension authors when they have created a build item but have not used it. I encountered this in quarkusio#38083 when I wrote something like: ```java UnremovableBeanBuildItem.beanTypes(Foo.class, Bar.class) ``` in a hurry and didn't stop to consider that the build item was never being produced
This makes the IDE warn extension authors when they have created a build item but have not used it. I encountered this in quarkusio#38083 when I wrote something like: ```java UnremovableBeanBuildItem.beanTypes(Foo.class, Bar.class) ``` in a hurry and didn't stop to consider that the build item was never being produced
This makes the IDE warn extension authors when they have created a build item but have not used it. I encountered this in quarkusio#38083 when I wrote something like: ```java UnremovableBeanBuildItem.beanTypes(Foo.class, Bar.class) ``` in a hurry and didn't stop to consider that the build item was never being produced