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
