squakez commented on issue #5519: URL: https://github.com/apache/camel-k/issues/5519#issuecomment-2119761376
Each of those trait require somehow the catalog to perform its logic. You can see in the code. The check we've added lately it's a guard to make sure the operator won't panic at runtime when the catalog is going to be required. As I wrote in the chat thread, each of the traits need to be carefully reviewed in order to make it work with the concept of "sourceless" Integration. Take the logging trait. You can see that the way we're expecting this trait to be configured is fully driven by the catalog [1], so, in its absence, you need to perform those settings via the right property substitution instead of a trait. An other possibility that we need to discuss and analyze would be the opportunity to let the user choose manually a Camel Catalog to attach in order to let it perform those trait configuration. However, this may defeat the entire sense of the feature itself, as, at this point, the user would need to provide too much configuration, versus the original idea where we wanted the user to be able to build externally and forget about any other detail. I reinforce the message stated before. This feature will naturally converge to something more stable and mature, which mean that, while iterating development we may discover things that required to be adjusted to fit into the Camel K operator wider design. [1] https://github.com/apache/camel-k/blob/32be17e5b9f69466586a3b14ce1d8813aa06beef/pkg/trait/logging.go#L122-L125 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
