It’s part of Karamel ;) (karaf with camel) PoC I started ;) Regards JB
> Le 20 août 2020 à 19:13, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > > Fully agree. As soon as we have a consensus, I will prepare an action plan > with clear topics to work all together on this. > > To be honest, I already tested/started some work around that as part of the > "cleanup" proposal I did couple of weeks ago. > > Regards > JB > >> Le 20 août 2020 à 19:09, Andrea Cosentino <anco...@gmail.com> a écrit : >> >> I'm +1 on this. But this needs to be a shared effort >> >> Il gio 20 ago 2020, 19:05 Jean-Baptiste Onofre <j...@nanthrax.net> ha >> scritto: >> >>> Hi Zoran, >>> >>> ServiceMix Bundles are definitely the way to go, and for instance I fixed >>> both spring-data and Elasticsearch bundles today fixing the >>> camel-elasticsearch-rest and camel-spring-redis components. >>> So, we can keep this approach. >>> >>> However, shipping dependency in camel components bundles have advantage: >>> 1. We don’t need the ServiceMix bundles anymore >>> 2. No brainer about the imports and some class loader trick, so it would >>> be easier >>> 3. Maintenance is quite the same >>> >>> Regards >>> JB >>> >>>> Le 20 août 2020 à 18:57, Zoran Regvart <zo...@regvart.com> a écrit : >>>> >>>> Hi Jean-Baptiste, >>>> I think this is almost a necessity, a lot of projects have stopped >>>> shipping OSGI manifest. I am a bit worried about maintenance overhead >>>> and limiting the ability to patch dependencies (esp. for security >>>> updates). >>>> >>>> I thought we get the best of both worlds with servicemix-bundles, not >>>> sure if it would be a good idea to adopt that approach in camel-karaf, >>>> i.e. create bundles for dependencies there? Obviously the downside >>>> would be more maintenance, which I don't think we can avoid in any >>>> case, right? >>>> >>>> zoran >>>> >>>> On Thu, Aug 20, 2020 at 8:14 AM Jean-Baptiste Onofre <j...@nanthrax.net> >>> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> Yesterday I spent a bunch part of the day fixing issue with >>> camel-elasticsearch (both Elasticsearch bundle and camel feature). >>>>> >>>>> I would like to propose a change in Camel Karaf about component >>> packaging. >>>>> >>>>> Right now, we use camel features repo to "install" the component with >>> its dependency. >>>>> I would like to propose to "embed" the component dependencies in the >>> component bundle itself. >>>>> >>>>> Basically the proposal is: >>>>> 1. To introduce a classifier "bundle" for component (can be done in >>> camel-karat) >>>>> 2. Dramatically simplify the feature to mostly install only the >>> component bundle >>>>> >>>>> There are pros/cons about this approach: >>>>> Pros: >>>>> - no need to have OSGi compliant dependency >>>>> - no class loader issue if the dependency is not OSGi compliant (as >>> all will be in the component class loader) >>>>> - coupling the component with the dependency version (resolution at >>> build time) >>>>> Cons: >>>>> - component bundle are larger than before (as they embed dependency) >>>>> - dependency version are strongly coupled within the component (which >>> is not necessary a bad thing) >>>>> >>>>> Alternatively, we can imagine a camel karaf component deployer that do >>> quite the same without embedding the dependency in the artifact (I can >>> create the bundle on the fly at runtime). >>>>> >>>>> Thoughts ? >>>>> >>>>> Regards >>>>> JB >>>> >>>> >>>> >>>> -- >>>> Zoran Regvart >>> >>> >
