I'm +1 on this. But this needs to be a shared effort Il gio 20 ago 2020, 19:05 Jean-Baptiste Onofre <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > >
