camel-k
camel-k copied to clipboard
apache
feat(runtime): get rid off camel k runtime dependency - WIP
Ref #4024
Requires still some work to be fully functional, but it should give an idea where to head the new design.
Release Note
NONE
:heavy_check_mark: Unit test coverage report - coverage increased from 34.8% to 35.3% (+0.5%)
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
:heavy_check_mark: Unit test coverage report - coverage increased from 34.8% to 35.8% (+1%)
:heavy_check_mark: Unit test coverage report - coverage increased from 34.8% to 35.8% (+1%)
:heavy_check_mark: Unit test coverage report - coverage increased from 34.8% to 35.8% (+1%)
:heavy_check_mark: Unit test coverage report - coverage increased from 34.8% to 35.8% (+1%)
:heavy_check_mark: Unit test coverage report - coverage increased from 34.8% to 36.3% (+1.5%)
understanding how camel-main works, we can see the camel.main.routesIncludePattern parameter replaces one of key parts of camel-k-runtime which is the ability to dynamically load the routes. My perception is this feature was not mature in camel-core at that time and camel-k-runtime was created to support this feature.
So, I think this is good, to materialize a camel-quarkus project. Also, there is no need anymore to the camel-k extension in camel-quarkus.
Also, there is no need anymore to the camel-k extension in camel-quarkus.
When I first saw this change, I wondered about that.
Does this mean we could remove the camel-k bits from CQ?
And could that change be done now so that it's complete in time for the next CQ LTS release? AFAIK, camel-k has not consumed the camel-k-runtime extension from CQ yet.
Also, there is no need anymore to the camel-k extension in camel-quarkus.
When I first saw this change, I wondered about that.
Does this mean we could remove the camel-k bits from CQ?
And could that change be done now so that it's complete in time for the next CQ LTS release? AFAIK, camel-k has not consumed the camel-k-runtime extension from CQ yet.
That's correct. As soon as this development is complete, we can remove the related ck-runtime bits from CQ and in general make the dependency process much smoother. It's possible that however we'll need to include the catalog into CQ or extend the one available there, but it should be done via maven plugin. Not reached yet that part, I expect this development to last still a bit :)
camel-k-runtime supports the dynamic reload of a route (no project rebuild) when the parameters are modified, for example, the master trait, if the resourceName parameter change with a -t master.resource-name=new-foo , the master trait in camel-k-runtime is backed by camel-master and not camel-quarkus-kubernetes, so this means that when the user changes the resource-name parameter camel-k-runtime just reloads the route, however in camel-quarkus-kubernetes it requires a rebuild of the project due to ConfigPhase.BUILD_TIME.
I think this is fine, as there are only 3 extensions in camel-k-runtime whom are affected by this hot reload feature not available in non dev mode in camel-quarkus.
I think this is fine, as there are only 3 extensions in camel-k-runtime whom are affected by this hot reload feature not available in non dev mode in camel-quarkus.
hot reload is not what we really want and MUST be disabled, if something changes, the pod must be restarted otherwise it is gonna be hard to do proper upgrade as things may change and fail out of control.
hot reload is not what we really want and MUST be disabled
By hot reload I meant the possibility of changing a configuration parameter that doesn't require a maven rebuild, like the master trait example I provided earlier, which just works.
hot reload is not what we really want and MUST be disabled
By hot reload I meant the possibility of changing a configuration parameter that doesn't require a maven rebuild, like the master trait example I provided earlier, which just works.
ah ok, I had the impression it was about hot reload of routes which in reality never happens as the pod is restarted
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 36.5% (+0.9%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 36.6% (+1%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 36.8% (+1.2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 36.8% (+1.2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 36.9% (+1.3%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 37.2% (+1.6%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 37.2% (+1.6%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 37.4% (+1.8%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.6% to 37.4% (+1.8%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.7% to 37.7% (+2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.8% to 37.8% (+2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.8% to 37.8% (+2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.8% to 37.8% (+2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.8% to 37.8% (+2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.8% to 37.8% (+2%)
:heavy_check_mark: Unit test coverage report - coverage increased from 35.8% to 37.8% (+2%)