Peter: I don't have any experience with enRoute yet (been using CXF and then Camel's REST DSL), but I'll try to put together some nice examples.
On 9 June 2016 at 11:25, Peter Kriens <peter.kri...@aqute.biz> wrote: > 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> 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> 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> >> 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> >>> 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 >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> >> -- >> http://about.me/milen >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> 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 >> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > 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 >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
