Hi, Yes, it’s possible to do the bundle wrapping in Camel Karaf. Basically, moving the OSGi statements/bundle packaging in Camel Karaf (either at build time or via a deployer). That’s possible, but I would do that in a second step.
Regards JB > Le 20 août 2020 à 19:29, Zoran Regvart <zo...@regvart.com> a écrit : > > Hi Jean-Baptiste, > perhaps for patching of dependencies we can see about independently > versioning/releasing the bundles. Would that help or would that just > add more overhead? > > zoran > > On Thu, Aug 20, 2020 at 7:19 PM Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: >> >> 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 >>>>> >>>>> >>> >> > > > -- > Zoran Regvart
