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 >> >>
