gansheer commented on issue #4639:
URL: https://github.com/apache/camel-k/issues/4639#issuecomment-1669228153
After some discussions with @claudio4j and some experiments with the xslt
components I think we can this feature can be done.
What I did was the following:
* 1/ read the file content from the configmap
* 2/ create a file in the appropriate folder /tmp/kit-xxxx/src/main/resources
* 3/ ensure it is added in the result of the build (what is injected in the
resulting kit container image) and usable
Why this process:
* For 1/ : since we are talking about build time external resource we can't
mount the configmap on the operator, that would be difficult to do and would
result on unwanted respins of operator/builder pod. Reading content from a
secret/configmap without volume mount is already a thing we do for user
provided settings.xml, so there is nothing new for us. The user should be
mindful of the quantity of configmaps added, but there is low risk as the data
stored in a ConfigMap cannot exceed 1 MiB.
* For 2/: the advantage of using /tmp/kit-xxxx/src/main/resource are:
* this folder should be in the workdir of the operator/builder pod so we
have writing permissions and it will be deleted at the end of the build
* this folder will be added automaticly in the
camel-k-integration-<version>.jar, therefor available after build
* For 3/: that would need more tests but from what my experiments the files
in the camel-k-integration-<version>.jar are available with
`.to("xslt:example.xslt")`
This would allow to add files as resources, but build property would still
use the `--build-property` flag as it needs to be added to
application.properties.
I feel what we really need is to start with defining use cases/example that
could be used to understand if it works of this proposal or if it needs some
adaptation.
--
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
