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
