I think the first point to address is about the Kamelet API [1]. Right now this is living (and evolving) as part of Camel K. If we decide to spin off something different, then we need a new project (or reuse the catalog) to take care of the API maintenance (also the CRD part). As an alternative, we can have the Kamelet (and KameletBinding) specification living separately (json, yaml, whatever) and Camel K just to reuse it in order to wrap around a Kubernetes consumable CRD.
I'd be +1 on both solutions. About the Knative examples raised by Claus, that one is autogenerated to showcase how to use them. It makes sense to have that generation in Camel K, as, the only way to consume those examples would be in Kubernetes. Regards, Pasquale. [1] https://github.com/apache/camel-k/blob/80cdea5b4b5250ad775c44ddf01a988ab8072a26/pkg/apis/camel/v1alpha1/kamelet_types.go#L61 On Fri, Nov 25, 2022 at 11:49 AM Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Thanks for starting this important topic. > I will come back with more thoughts later. > > But one thing that stood out to me is that the kamelets documentation today > is tied into knative [1] and kamelet bindings. > it looks a bit like the documentation is auto generated for that part. > There's a lot of complex stuff there that we should not show to the user at > first hand. > Instead documentation about knative should IMHO be in the camel-k > documentation. > > [1] - > https://camel.apache.org/camel-kamelets/0.9.x/aws-ddb-sink.html#_usage > > > > > > On Fri, Nov 25, 2022 at 9:56 AM Andrea Cosentino <anco...@gmail.com> > wrote: > > > Hello, > > > > Kamelets are becoming an important and universal higher-level components > / > > building-blocks of Apache Camel; that are universal usable in all of > Camels > > runtimes and projects, whether its Camel on Spring Boot, Camel > Standalone, > > Camel Kafka Connector, Camel Quarkus, Camel JBang and Camel K as well. > > > > In the beginning kamelets were just tied to Camel K and therefore they > were > > documented and released through the Camel K subproject. The situation is > > now really different. Camel-Kamelets and the kamelets catalog is now part > > of the full chain of Camel releases. > > > > I personally have some ideas around it. In my opinion camel-jbang should > be > > the starting point for developing a camel application: Kamelets could be > an > > extremely important accelerator in the getting started experience. > > - Install camel-jbang > > - Select your Kamelet for source and sink > > - run your integration > > - It works? Cool. It doesn't work? Let's see why > > - My integration is now stable, I want to pass to another level. I could > > still use the kamelets, but also I could switch to a full Camel route. > Let > > me select my runtime: Quarkus, Spring Boot, Camel K or plain camel. Let > me > > export the project to my selected runtime. > > - Ready to go. > > > > All of this could also pass through Camel-Karavan, without touching code, > > or touching very few lines of code. We have really a lot of power and a > lot > > of stuff to improve. > > > > In my opinion we should work on multiple sides: > > - make it possible to load different kamelet catalogs (complex cases, > > custom kamelets, etc.) > > - improve the default Kamelets catalog > > - Focus on the camel-jbang experience > > - Maybe try to think about a Kamelets Marketplace or catalog marketplace > > > > My proposal is also to note in terms of documentation that kamelets are > not > > only tied to Camel K, but some fundamental building block in the Camel > > experience. > > > > I think we should create some epic around this and try to follow this > path. > > > > Any feedback, comments and thoughts are welcome. Please let me know what > > you think. > > > > Cheers, > > Andrea > > > > > -- > Claus Ibsen > ----------------- > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
