Thanks Andrea, yes, there will be quite some work to do as we have many circular references and other aspects which we need to move off from Camel K. The CRDs project should be partially moved as well, as it contains the dependency used by the tooling. Fortunately Kamelets should not have references on others API, but we'll discover while working on it.
Cheers, Pasquale. On Tue, Sep 3, 2024 at 8:15 AM Andrea Cosentino <anco...@gmail.com> wrote: > Hello Pasquale, > > I think it makes sense. > > This will mean moving the following project and the related crds in base, > right? > > https://github.com/apache/camel-k/tree/main/java/crds > > > > Il giorno lun 2 set 2024 alle ore 17:18 Pasquale Congiusti < > pasquale.congiu...@gmail.com> ha scritto: > > > Hi folks, > > in the past we've discussed the opportunity to move the specification of > > Kamelet from Camel K to Camel since Kamelets have been a general concept > > for some time. I'd like to set the ground for a shared decision on what > to > > achieve. I will create a JIRA, but, before, I'd like to understand if we > > all agree with the following points. > > > > 1. We should move the CRD from Camel K to the Kamelet catalog > > repository. It's important we familiarize ourselves with the > Kubernetes > > API > > management policy, above all with deprecation policy [1] and make sure > > to > > avoid any change that would break any public clients compatibility. > The > > API > > may be used by any application/tool outside Apache Camel and it is > > vital to > > make sure we respect the contract. Kamelets API has been GA in v1 > since > > a > > while and it's quite stable. I suggest discussing any non-trivial > change > > publicly in order to always understand the potential impact outside > the > > Apache Camel ecosystem. > > 2. We should rethink the bundling process for the provided Kamelet > > catalog in Camel K. Above all, we need to align with the expected > > behavior > > provided by Camel core. The distribution model that it seems more > > obvious > > is to leverage the catalog distributed as a dependency with Camel > core. > > That means that, by default, the Kamelet version used for catalog > > provided > > Kamelet at runtime will be the one distributed with the given core > > version. > > > > Let me know what you people think. > > > > Thanks and regards, > > Pasquale. > > > > [1] https://kubernetes.io/docs/reference/using-api/deprecation-policy/ > > >
