On Mon, Aug 5, 2024 at 9:07 AM James Netherton <jamesnether...@gmail.com> wrote:
> Thanks Pasquale for the explanation! > > > I'd suggest parking the work done so far in a branch that could be taken > over in the future if needed > > We could keep it in for CQ 3.14.0 and then remove for 3.15.0 which will > (hopefully) be an LTS release. I can also cut a branch and document it > somewhere too. > > Yes that seems like a good plan. > -- > James > > On Tue, 30 Jul 2024 at 09:50, Pasquale Congiusti < > pasquale.congiu...@gmail.com> wrote: > > > Hi James, > > I don't know if somebody is going to continue that work. However, let me > > add some context that may help with making the decision. > > > > At the beginning of the year I was working on some development with the > > goal to eventually remove the runtime at all [1]. However the work was > > stopped as we decided that it was better to keep a provider into the > > runtimes (eventually also in Springboot) in order to control certain > > behaviors (for instance altering routes for cronjobs or dynamic loading > of > > properties). > > > > The best approach would be to go even a step further and try to harmonize > > those common cloud capabilities directly in the core, in order any > runtimes > > to be able to leverage a common mechanism wherever that's possible. > > > > From Camel K perspective, if somebody is willing to continue that work > and > > have a fully functional artifact would be good as it reduced the need to > > maintain Camel K Runtime project separately (which, at this stage is only > > released when Camel Quarkus is released). If nobody is going to work in > the > > immediate future I'd suggest parking the work done so far in a branch > that > > could be taken over in the future if needed. > > > > Cheers, > > Pasquale. > > > > [1] https://github.com/apache/camel-k/pull/5090 > > > > On Tue, Jul 30, 2024 at 9:30 AM James Netherton < > jamesnether...@gmail.com> > > wrote: > > > > > Hi everyone, > > > > > > I wanted to open a discussion about the camel-k extension module and > > Maven > > > plugins that live in the Camel Quarkus project: > > > > > > https://github.com/apache/camel-quarkus/tree/main/extensions/camel-k > > > > > > > > > https://github.com/apache/camel-quarkus/tree/main/tooling/camel-k-catalog-model > > > > > > > > > https://github.com/apache/camel-quarkus/tree/main/tooling/camel-k-maven-plugin > > > > > > There was a plan to move the majority of the camel-k-runtime project > into > > > either Camel or Camel Quarkus. > > > > > > https://github.com/apache/camel-quarkus/issues/4283 > > > > > > We've had the camel-k extension in Camel Quarkus for almost 12 months. > > > During this time, the CQ camel-k extension and the camel-k-runtime > > project > > > have diverged. > > > > > > Is it still the intention that camel-k will eventually consume this > work? > > > > > > I'm asking because there is a (minor(ish)) overhead in maintaining the > CQ > > > camel-k modules. And since the number of Maven modules in CQ is ever > > > increasing, I like to take every opportunity to trim stuff from the > > project > > > whenever possible. > > > > > > -- > > > James > > > > > > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
