Open squakez opened 11 months ago
This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!
@squakez do I get it right that basically this:
should not be necessary? If there are other places where builder trait is aware of Quarkus trait and shouldn't, can you specify them please? (or just give me a hint)
I'll try to address it, it will take me long time, but the issue does not seem urgent.
Yes. The problem is the coupling we may have among traits. We need to find a way to decouple. However it may require a deep review of how this would affect the entire operator building process. Feel free to have a look and provide any better design to improve this part.
Understood, thanks
The builder trait needs to know certain parameters available in the Quarkus trait in order to perform its tasks accordingly (ie, native image task definition and pod resource configuration). However, the quarkus trait is executed after the builder task and is required by the Quarkus trait which is in charge to influence the Build custom resource initialized in the builder trait.
We need to change the process to make the builder trait completely agnostic from the Quarkus trait, making the quarkus trait able to influence the Build if that is what is needed.