Thanks Andrea for the post. I also +1 to the proposal. What I like the most too is the idea of the Kamelets marketplace. I too believe that creating a vibrant community-based marketplace is the essential step for the future success of Camel and Kamelets. We should nurture a place something similar to JBang AppStore or VS Code Marketplace for Kamelets!
On Sat, Nov 26, 2022 at 4:29 PM Otavio Rodolfo Piske <angusyo...@gmail.com> wrote: > 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 < > pasquale.congiu...@gmail.com> 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 <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 > > > > > > > > -- > Otavio R. Piske > http://orpiske.net > -- Tadayoshi Sato
