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
