Hello Pasquale, +1 on moving the Java CRD model generation as it is a source of circular dependencies. But what about the pure CRD YAML definitions ( https://github.com/apache/camel-k/tree/main/pkg/resources/config/crd/bases)? >From a Camel K operator perspective wouldn't it be weird to loose the ownership of those resources?
When speaking of circular dependencies we should think about Kamelets catalog repository, too. The utilities located in the catalog represent another source of circular dependencies. Maybe it makes sense to move the Java CRD model and the Kamelets into Camel: https://issues.apache.org/jira/browse/CAMEL-21049 Cheers, Christoph Am Di., 3. Sept. 2024 um 09:25 Uhr schrieb Pasquale Congiusti < pasquale.congiu...@gmail.com>: > 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/ > > > > > >
