tadayosi commented on PR #3471: URL: https://github.com/apache/camel-k/pull/3471#issuecomment-1192163584
> However, if a property change (a runtime property, as build time property are specified in the `builder` trait), we probably don't want to rebuild the kit. I'm not sure how to tackle this, maybe we should split the trait? Thanks. That's very valid point. It also looks not so easy to split the trait and at the same time keep backward compatibility. And some `common` E2E tests still failing may suggest there are a few more traits that would implicitly influence kits... I think there's a bit of mess in traits about what actually influence kits and what do not and their relationship with the return value of the `InfluencesKit()` methods that should be sorted out. But I'm a bit intimidated to try to address it within v1. We should rather tackle it in Camel K v2. I'll explore another approach that checks possibility of nil integration in every trait, instead of making Camel trait explicitly influencing kits and applying traits that influence kits during kit building. -- 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]
