I'd love to see better DS support in Apache Camel. Right now, the lack of
support means I either have to use blueprint everywhere or some fun hybrid
of some services being managed by DS and others being managed by blueprint.

There's some experimental support for Felix's SCR annotations in Camel, but
no real support for a proper DS version.

On 9 June 2016 at 09:24, Peter Kriens <[email protected]> wrote:

> Well, OSGi is a component model so it would be surprising if we all
> thought the same, especially in open source. At least OSGi allows full
> co-operation between these ‘camps’.
>
> That said, I think is quickly getting closer to the DS ‘camp’, Christian
> seems to spend a lot of effort.
>
> Kind regards,
>
> Peter Kriens
>
> On 9 jun. 2016, at 12:48, Milen Dyankov <[email protected]> wrote:
>
> I "like" how someone described OSGi community divided into camps! From one
> side, it kind of makes me fell better to know I'm not the only one having
> this strange feeling! From the other side, it makes me sad that more people
> are feeling this way.
>
> On Thu, Jun 9, 2016 at 11:44 AM, Daniel McGreal <[email protected]>
> wrote:
>
>> That was me, and yes, that’s the correct interpretation - the feedback as
>> several other contributors*.
>>
>> We don’t like to take the implied responsibility for maintaining jars we
>> repackage ourselves with OSGi MANIFEST.MF headers for a variety of reasons.
>> Luckily the situation is getting better, based on my experience.
>>
>>    - Generation tools are better, more convenient and therefore more
>>    prevalent (thanks bnd-maven-plugin).
>>    - OSGi headers are cropping up from source more and more regularly
>>    (I’d love to see another scan of central to see how many jars supply them,
>>    broken down by popularity).
>>    - ServiceMix provides distributions, though they sometimes seemingly
>>    haven’t been tested.
>>    - Karaf wrap means things frequently just work at deployment time
>>
>>
>> Best, Dan.
>>
>> * Balazs, I’d meekly suggest grouping the ‘other’ responses and including
>> into the graphs where significant. For example, Karaf shell clearly
>> deserves a place if the extra responses were grouped, as does Vaadin for
>> UIs, etc.
>>
>> On 8 Jun 2016, at 20:53, Balázs Zsoldos <[email protected]>
>> wrote:
>>
>> My guess is that OSGi metadata here mean the OSGi MANIFEST headers and
>> the sentence mean something like the following: Lot's of technologies do
>> not have the OSGi MANIFEST headers in their jars, but thanks to ServiceMix
>> the situation is getting better (as ServiceMix re-packages many popular
>> jars)
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> http://about.me/milen
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to