squakez opened a new issue, #5019: URL: https://github.com/apache/camel-k/issues/5019
### Requirement Dear community, first of all, happy 2024 to all of you. As usual, in this time of the year, we want to take the opportunity to reason and discuss which should be the project goals for the year. I will start this conversation and invite everybody to include their thoughts or their desires for this year development. ## Status of 2023 roadmap Last year we dedicated a lot of effort to redesign the core of the project which ended in the new Camel K 2.0. We have mainly worked around the possibility to make the build more enterprise ready and flexible enough to eventually onboard any runtime. We managed to have a first possibility to run and import any runtime (likely available in coming Camel K 2.2). We can say that we set the track for a simpler evolution of the project in that sense. ## Area of developments for 2024 We have some leftover from last year we may want to include in 2024 roadmap, above all to close the loop around a complete build experience for other runtimes. Additionally I'd like to set a main goal for this year around the possibility to **make Camel K as the technology that enables other tools in the Camel ecosystem on Kubernetes**. I'll come back on this point later. Here it follow an unsorted list of areas which I think we should deserve attention for 2024: * Expose meaningful status of Integrations for other tools to interact in a Kubernetes "native" way * Complete the build experience and let the user be able to build any Camel runtime * Remove `kamel` CLI in favour of other toolings * Enhance the project organization * Enhance quality of code * Discuss how to enable Kamelet versioning I'll try to add some context in words in order to ease the meaning of each point. ### Expose meaningful status of Integrations for other tools to interact in a Kubernetes "native" way This would encompass everything around the "observability" of a Camel application. Whether the application is built and run by the Camel K operator or externally we should be able to read the status and expose meaningful information in a Kubernetes "native" way. This will simplify the integration of other tools in Kubernetes which will be able to communicate via the Integration custom resource. Put in different words, any tool should be able to use the primitives available in Camel K in order to understand what's going on around a Camel application. ### Complete the build experience and let the user be able to build any Camel runtime We are just on the last mile to let this happen. We need to polish some aspect and be able to let the operator build other runtimes. At the same stage we must let the user choose how to build the application (even externally) and let the operator "operates" the Camel application. ### Remove `kamel` CLI in favour of other toolings Although it's a great utility, the `kamel` CLI is kind of limiting the development of the operator to a certain extent. We have already other initiatives ongoing which will simplify the creation of an Integration custom resource. Camel Jbang is one of them (we already started some plugin development on it). ### Enhance the project organization There are aspects of the project organization that require some attention. At this stage the main problem I see is the presence of Kamelets API definition in Camel K, whilst, it should be directly in the Kamelets catalog now that Kamelets are a Camel generic thing. ### Enhance quality of code Last year we have worked on a nice feature that will calculate the testing coverage of our project. I am not a big fan of putting gate numbers but I think that by increasing the coverage we'll definitely reduce the surface for bugs discovered by the users. We should also make more use of the unit test mocking the controllers vs e2e test as the second requires more resources to execute and delay a lot the feedback on each PR (not to say that some of them are known to be flaky). ### Discuss how to enable Kamelet versioning This is something that has not a high priority, but, during the year I'd like to kick off the discussion to get ideas around how we can have an opinionated way to have multiple version for Kamelets. We have suffered this problem in various way and I think we need to find a clear way to solve it. ### Problem a ### Proposal _No response_ ### Open questions _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
