squakez commented on issue #2320: URL: https://github.com/apache/camel-k/issues/2320#issuecomment-922718785
I've analyzed this more deeply. It is possible to think a trait, probably `container` trait, to handle `--config` and `--resource`, moving the parsing logic directly in the trait (which is also in charge to mount the volumes, so it even simplify the "modularity"). However we have a big limitation when it comes to `file` usage. The file content must be stored within the same `Integration`, so that it can be transformed on the fly into a `configmap` and used. The trait is executed by the `operator` and it won't have access to the file content (unless we store it previously, as we're doing now). One possibility would be to get rid of `file`. After all, the user should have familiarity with cloud native way of storing resources (ie, `configmap`) and create them beside the integration. The same would apply to `--openapi` and would deprecate `.integration.spec.resources` as well. @astefanutti @nicolaferraro @lburgazzoli wdyt? -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
