You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2020/08/20 06:13:59 UTC
[Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
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
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi,
Yes, it’s possible to do the bundle wrapping in Camel Karaf. Basically, moving the OSGi statements/bundle packaging in Camel Karaf (either at build time or via a deployer).
That’s possible, but I would do that in a second step.
Regards
JB
> Le 20 août 2020 à 19:29, Zoran Regvart <zo...@regvart.com> a écrit :
>
> 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 <jb...@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 <jb...@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 <an...@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 <jb...@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 <jb...@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
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Zoran Regvart <zo...@regvart.com>.
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 <jb...@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 <jb...@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 <an...@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 <jb...@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 <jb...@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
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
It’s part of Karamel ;) (karaf with camel) PoC I started ;)
Regards
JB
> Le 20 août 2020 à 19:13, Jean-Baptiste Onofre <jb...@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 <an...@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 <jb...@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 <jb...@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
>>>
>>>
>
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <an...@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 <jb...@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 <jb...@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
>>
>>
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Andrea Cosentino <an...@gmail.com>.
I'm +1 on this. But this needs to be a shared effort
Il gio 20 ago 2020, 19:05 Jean-Baptiste Onofre <jb...@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 <jb...@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
>
>
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <jb...@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
Re: [Camel Karaf|Discussion] Embed component dependencies as private
package of the component or camel component deployer
Posted by Zoran Regvart <zo...@regvart.com>.
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 <jb...@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