No, sorry! This answer came without contact details so I cannot ask the one who answered privately.
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) Regards, *Balázs* On Wed, Jun 8, 2016 at 8:35 PM, Scott Lewis <[email protected]> wrote: > Hi Balazs, > > Can anyone provide details on what metadata is meant by this statement: > > > > *Availability of OSGi metadata from source (or correctness when > available), though it’s improving *Thanksinadvance, > > Scott > > > > On 6/8/2016 7:04 AM, Balázs Zsoldos wrote: > > Hi, > > here is the fourth and last part of the series: > <https://everitorg.wordpress.com/2016/06/08/how-do-you-use-osgi-part-4/> > https://everitorg.wordpress.com/2016/06/08/how-do-you-use-osgi-part-4/ > > I hope it will be as instructive to you as it was me to see the answers. > > Thanks for all of you who took the time to answer! > > Regards, > *Balázs* > > On Fri, Jun 3, 2016 at 2:06 PM, Balázs Zsoldos < > <[email protected]>[email protected]> wrote: > >> Hi, >> >> here is the third part of the answers (a bit longer than the previous >> ones): >> <https://everitorg.wordpress.com/2016/06/03/how-do-you-use-osgi-part-3/> >> https://everitorg.wordpress.com/2016/06/03/how-do-you-use-osgi-part-3/ >> >> The next one will be the last one. >> >> Regards, >> *Balázs* >> >> >> On Mon, May 30, 2016 at 10:56 AM, Balázs Zsoldos < >> <[email protected]>[email protected]> wrote: >> >>> Will you please notify us on the other parts via mailing list as well? >>> >>> >>> I have just finished the second part: >>> https://everitorg.wordpress.com/2016/05/30/how-do-you-use-osgi-part-2/ >>> >>> Thanks again for the answers! >>> >>> Balazs >>> >>> >>> On Thu, May 26, 2016 at 6:39 PM, < <[email protected]> >>> [email protected]> wrote: >>> >>>> That is great, thank you for the work ,) >>>> >>>> Imust admit I was not quite clear what questions you wanted to answer >>>> for your own projects, but seeing the answers it is certainly usefull on >>>> its own. Will you please notify us on the other parts via mailing list as >>>> well? >>>> >>>> I wonder if that would be a nice project for the OSGi consortium to >>>> prepare and conduct a community survey. It has become quiet about OSGi, a >>>> widely distributed survey and result could get some traction back. >>>> >>>> Bernd >>>> >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> -----Original Message----- >>>> From: "Balázs Zsoldos" < <[email protected]> >>>> [email protected]> >>>> To: OSGi Developer Mail List <[email protected]> >>>> Sent: Do., 26 Mai 2016 18:17 >>>> Subject: Re: [osgi-dev] How do you use OSGi? >>>> >>>> Hi, >>>> >>>> I see that a question form with some simple question motivated people to >>>> write 35 emails on this thread. I am euphoric to see that as these >>>> discussions can be very useful for others, too. For me, they were >>>> useful. >>>> >>>> I started to write an e-mail with the summary of responses, but it got >>>> too >>>> long. I wanted to attach pictures, but I think they would not be shown >>>> in >>>> mailing list archives. I do not know how others are with it, but I like >>>> short texts with pictures :). >>>> >>>> Therefore, I split the content into 2-3 parts and release it as a >>>> series of >>>> blog posts. The first one is here: >>>> https://everitorg.wordpress.com/2016/05/26/how-do-you-use-osgi-part-1/ >>>> >>>> Kind regards, >>>> *Balázs* >>>> >>>> >>>> On Wed, May 25, 2016 at 9:20 AM, Jean-Baptiste Onofré < >>>> <[email protected]>[email protected]> >>>> wrote: >>>> >>>> > Hi, >>>> > >>>> > It's a good approach. We use the same approach in >>>> camel-blueprint-test to >>>> > "fake" OSGi services (as describe here: >>>> > >>>> <http://blog.nanthrax.net/2014/08/testing-utest-and-itest-apache-camel-blueprint-route/> >>>> http://blog.nanthrax.net/2014/08/testing-utest-and-itest-apache-camel-blueprint-route/ >>>> ) >>>> > However, it's a bit "limited" compared to a full OSGi framework. >>>> > >>>> > I like what you did to show that we can "embed" OSGi applications in >>>> > spring-boot. >>>> > Another interesting approach would be to show how to embed the OSGi >>>> > framework or container (Karaf Minimal/Static/Main) in spring-boot >>>> too. Or >>>> > even better showing how to use karaf-boot to do it for us. >>>> > >>>> > Regards >>>> > JB >>>> > >>>> > >>>> > On 05/25/2016 09:12 AM, Christian Schneider wrote: >>>> > >>>> >> Yes .. pojosr (connect) works quite nicely. I even managed to bridge >>>> to >>>> >> the world of spring-boot now. >>>> >> >>>> >> >>>> <https://github.com/cschneider/decanter-docker/tree/master/spring-boot-starter-decanter> >>>> https://github.com/cschneider/decanter-docker/tree/master/spring-boot-starter-decanter >>>> >> >>>> >> In this module I define a spring boot extension for Karaf Decanter. >>>> It >>>> >> starts a minimal decanter inside a spring boot application. >>>> >> >>>> >> Basically the idea is to forward all log informations (later also JMX >>>> >> beans) into an embedded decanter that can then be configured to >>>> forward >>>> >> the logs >>>> >> using any protocol decanter supports. In my case it forwards to a >>>> kafka >>>> >> broker. There a full scale decanter picks up the logs, processes them >>>> >> and forwards to ES. >>>> >> >>>> >> In the spring boot app you can then define a logger that forwards the >>>> >> logs into decanter using EventAdmin. >>>> >> >>>> >> >>>> <https://github.com/cschneider/decanter-docker/blob/master/taskservice/src/main/resources/logback.xml> >>>> https://github.com/cschneider/decanter-docker/blob/master/taskservice/src/main/resources/logback.xml >>>> >> >>>> >> I was quite surprised that I was able to reuse the normal decanter >>>> >> bundles including config handling and DS without any changes. >>>> >> This is very helpful as it allows to reuse OSGi code that has to run >>>> >> inside a non OSGi application for some reason. >>>> >> >>>> >> Christian >>>> >> >>>> >> >>>> >> On 25.05.2016 08:42, Peter Kriens wrote: >>>> >> >>>> >>> In PojoSR and thus I assume you can install, start, and stop >>>> bundles. >>>> >>> You cannot update, resolve, or uninstall for obvious reasons. It is >>>> >>> uncannily close to a real framework :-) >>>> >>> >>>> >>> Kind regards, >>>> >>> >>>> >>> Peter Kriens >>>> >>> >>>> >>> >>>> >>> On 24 mei 2016, at 23:43, Neil Bartlett >>>> >>>> <<mailto: <[email protected]>[email protected]> >>>> <[email protected]>[email protected]> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> On 24 May 2016, at 21:57, Christian Schneider >>>> >>>>> <<mailto: <[email protected]>[email protected]> >>>> <[email protected]>[email protected]> wrote: >>>> >>>>> >>>> >>>>> On 24.05.2016 21:02, Scott Lewis wrote: >>>> >>>>> >>>> >>>>>> >>>> >>>>>> Yeah you can do this, but my observation is that very few are. >>>> >>>>>> >>>> >>>>>> I would also suggest that the classes/API in the launch package >>>> >>>>>> (e.g. BundleFinder) are/would be essential [1], as launch >>>> >>>>>> configuration is extremely important to address more than a few >>>> use >>>> >>>>>> cases. Actually, I also think that some standard config >>>> >>>>>> properties (e.g. BundleFinder impls, or specific bundles to be >>>> >>>>>> added/started on startup) would be useful, but I haven't thought >>>> >>>>>> that through yet. >>>> >>>>>> >>>> >>>>>> I agree. A big part is finding and selecting the bundles to >>>> start. >>>> >>>>> This is not covered by FrameworkFactory. >>>> >>>>> >>>> >>>> >>>> >>>> I’m confused, are you still talking about Connect? In Connect, you >>>> >>>> cannot install, update or uninstall bundles, because that would >>>> >>>> require the full OSGi lifecycle and classloaders. Instead, Connect >>>> >>>> automatically gives you ersatz bundles representing JARs on the >>>> >>>> classpath. You can, however, start and stop these bundles because >>>> >>>> that only requires setting a flag and calling a callback (they are >>>> >>>> all started by default when the framework starts). >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> Another interesting part would be a kind of health check. >>>> >>>>> When I start a feature or bundles in karaf I can use the shell to >>>> >>>>> introspect if the bundles are all resolved and start correctly and >>>> >>>>> which DS components are started and which are not. >>>> >>>>> For embedded OSGi where you typically do not have a shell it would >>>> >>>>> be great to have some configureable health checks that tell you if >>>> >>>>> something might be wrong in your setup. >>>> >>>>> One example would be that I expect that all bundles are started >>>> and >>>> >>>>> all DS components come up. I am not sure if this requires an API >>>> >>>>> though. It could simply be a bundle. >>>> >>>>> Of course this would be interesting for other OSGi deployments >>>> too. >>>> >>>>> >>>> >>>> >>>> >>>> This area is always tricky because there are common scenarios in >>>> >>>> which some bundles/components do not start but the overall >>>> >>>> application is still considered to have successfully started. So >>>> the >>>> >>>> health-check would need application-specific knowledge. You’re >>>> right >>>> >>>> that this can be implemented in a bundle. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Christian >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Christian Schneider >>>> >>>>> <http://www.liquid-reality.de>http://www.liquid-reality.de >>>> >>>>> >>>> >>>>> Open Source Architect >>>> >>>>> <http://www.talend.com>http://www.talend.com >>>> >>>>> _______________________________________________ >>>> >>>>> OSGi Developer Mail List >>>> >>>>> <[email protected]>[email protected] <mailto: >>>> <[email protected]>[email protected]> >>>> >>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> OSGi Developer Mail List >>>> >>>> <[email protected]>[email protected] <mailto: >>>> <[email protected]>[email protected]> >>>> >>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> OSGi Developer Mail List >>>> >>> <[email protected]>[email protected] >>>> >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>>> >> >>>> >> >>>> >> -- >>>> >> Christian Schneider >>>> >> <http://www.liquid-reality.de>http://www.liquid-reality.de >>>> >> >>>> >> Open Source Architect >>>> >> <http://www.talend.com>http://www.talend.com >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> OSGi Developer Mail List >>>> >> <[email protected]>[email protected] >>>> >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >> >>>> >> >>>> > -- >>>> > Jean-Baptiste Onofré >>>> > <[email protected]>[email protected] >>>> > <http://blog.nanthrax.net>http://blog.nanthrax.net >>>> > Talend - <http://www.talend.com>http://www.talend.com >>>> > >>>> > _______________________________________________ >>>> > OSGi Developer Mail List >>>> > <[email protected]>[email protected] >>>> > <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> 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 > [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
