Hi Andrea, I think those are good ideas and I believe it would be beneficial for the project to make the Kamelets a more prominent concept within our projects. I believe we can reach a larger audience by doing so. In particular, I like the idea of the Kamelets marketplace.
All in all, it's +1 from me. I also would like to comment about one point that Claus mentioned: "But one thing that stood out to me is that the kamelets documentation today is tied into knative [1] and kamelet bindings." I agree. I am working on a plan to reorganize our documentation - which I will share with the community as soon as I have it done - and I will take the points you raised into consideration as well. IMHO, this is very important if we want to raise the prominence of Kamelets in the future. Kind regards On Fri, Nov 25, 2022 at 3:53 PM Pasquale Congiusti < [email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > > 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 > > > -- Otavio R. Piske http://orpiske.net
