Isn’t this the beauty of open source? :-) If you start an OSGi enRoute example like the Vaadin & JDBC I can help out with advice. Any experiences can then be fed back into Camel.
Kind regards,
Peter Kriens
> On 9 jun. 2016, at 18:00, Matt Sicker <mattsic...@apache.org> wrote:
>
> 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 <peter.kri...@aqute.biz
> <mailto:peter.kri...@aqute.biz>> 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 <milendyan...@gmail.com
>> <mailto:milendyan...@gmail.com>> 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 <d.j.mcgr...@gmail.com
>> <mailto:d.j.mcgr...@gmail.com>> 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 <balazs.zsol...@everit.biz
>>> <mailto:balazs.zsol...@everit.biz>> 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
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>>
>> --
>> http://about.me/milen
>> <http://about.me/milen>_______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
