Hi guys, As I didn't receive any objections about this one, I will move forward and open the PRs.
Regards JB On Mon, May 2, 2022 at 3:07 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi guys, > > I worked on several changes on camel-karaf that I would like to > propose as PR asap: > > Short term (now): > > 1. Remove platform module to directly use features module > I've removed the platform maven module, and moved camel-karaf features > directly in a new features module (as we do directly in Karaf). > > 2. Add whiteboard support in the core > The idea is to add CamelContext and Route whiteboard support directly > in camel-core-osgi. The core will directly have a whiteboard for > CamelContext and RouteBuilder services. > It means that the users won't have to create the CamelContext > explicitly but just register a CamelContext service. For the > RouteBuilder, it's possible to use a single CamelContext for all > routes, or to define a CamelContext ID, controlling the routes > register in each CamelContext. > > 3. Extending itests > I added a bunch of itests, at least testing camel component features > deployment and, when possible, simple test case. Those itests are not > executed by default but by a dedicated profile. > > Mid term (during summer): > > 4. As already proposed, I created a tool that creates "uber" camel > component bundles, using a descriptor. The purpose is to avoid > maintenance/creation of camel component features, and use a single > classloader for the component in Karaf (that allows us to work with > any component, OSGi compliant or not). For licensing reasons, we won't > provide directly the binary bundle, but the descriptor of the > component that will be created at build time or runtime. > For instance, deploying camel-azure-cosmosdb won't require a feature > anymore, just: > > bundle:install > bundle:org.apache.camel/camel-azure-cosmosdb/3.16.0?descriptor=http://github.com/apache/camel-karaf/descriptors/camel-azure-cosmosdb.json > > I'm testing right now if I can use the component pom.xml directly > (instead of having a dedicated json file). > I'm currently testing the deployment (runtime/buildtime/static). I > will provide more details. > I will use this approach as replacement of ServiceMix Bundles too. > > I'm still working on this one, but you have the rough idea. > > 5. As part of camel-karaf, I will introduce a new tooling named > karamel. The purpose is to create Karaf4 (and later Karaf5) runtime > with routes easily. > Basically, you can do something like: > $ karamel build --style k4 myroute1.jar myroute2.xml ... > It creates a tar.gz karamel runtime (karaf with camel) ready to run. > You can also do: > $ karamel image myroute1.jar myroute2.xml ... > Then it creates a docker image on the local docker daemon, ready to be run. > > Thoughts ? > > If there's no objection, I will move forward on the "short term" tasks. > > If you have any questions/comments, please let me know. > > As you can see, we are "restarting" camel-karaf with new cool stuff ;) > > Thanks, > Regards > JB
