FYI, One thing few people realize is that Service Loader Mediator does allow your providers to be consumed via the service registry.
If you use the bnd SPI annotations I already mentioned this is a default behavior. - Ray On Thu, May 21, 2020 at 9:19 AM Raymond Auge <raymond.a...@liferay.com> wrote: > Another alternative designed specifically for this scenario is the OSGi > Service Loader Mediator Specification [1]. > > Java's default _service_ mechanism is Service Loader SPI. The Service > Loader Mediator Specification adds a veneer of pure metadata over this to > allow it to function in OSGi. > > There are even SPI annotations [2] in the Bnd project to help with this > (you should be able to use these with the maven-bundle-plugin if necessary). > > In this way the code is exactly 100% identical in OSGi and outside it. > > Sincerely, > - Ray > > [1] > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html > [2] https://bnd.bndtools.org/chapters/240-spi-annotations.html > > On Thu, May 21, 2020 at 3:54 AM Neil Bartlett via osgi-dev < > osgi-dev@mail.osgi.org> wrote: > >> Along the lines of Bernd's answer, here is what I do: >> >> 1. Use declarative services. >> 2. For injection of service references, prefer constructor injection. >> 3. The component implementation should be in a private package. However, >> non-OSGi consumers don't know anything about exported versus private >> packages, so they just directly instantiate the DS component instance. >> Because we used constructor injection, it's clear what dependencies >> they need to provide to the component. >> 5. If there is a need to interact with OSGi's APIs (e.g. BundleContext), >> keep that code in a separate factory component. Put this code in a separate >> class from the "business logic". Don't necessarily worry about using a >> separate package for this... because Java ClassLoading is extremely lazy, >> non-OSGi consumers will only be exposed to the OSGi-specific code if they >> go out of their way to load it. >> >> On Thu, 21 May 2020 at 01:50, Bernd Eckenfels via osgi-dev < >> osgi-dev@mail.osgi.org> wrote: >> >>> Hello, >>> >>> We typically use declarative services (DS) with the Maven bundle plugin >>> and Annotations. This leaves no (optional) OSGi framework dependency and >>> still allows a compliant container to manage the lifecycle of the component. >>> >>> In some (rare) cases when you have to deal with service references or >>> OSGi context and you need the core API it does also not hurt to make it >>> optional, as long as the class which uses it (and would not resolve) is not >>> used by the stand alone code. This is typically the case for OSGi first >>> components which are made compatible with stand alone unit tests. >>> >>> You can even have the factory receive the service, and therefore be >>> useable inside the runtime. >>> >>> An alternative is, to just have the bundle headers and no service, this >>> is still useful to OSGi code in many instances where you don't have a >>> service lifecycle. >>> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> ------------------------------ >>> *Von:* osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> >>> im Auftrag von David Leangen via osgi-dev <osgi-dev@mail.osgi.org> >>> *Gesendet:* Thursday, May 21, 2020 12:44:04 AM >>> *An:* osgi-dev@mail.osgi.org <osgi-dev@mail.osgi.org> >>> *Betreff:* [osgi-dev] Library development >>> >>> Hi! >>> >>> What is the best way to prepare a library to OSGi-compatible, but not >>> force the use of OSGi (including forcing transitive dependencies)? >>> >>> The library should be split into api / implementation and offered as a >>> service, but it should be possible for those who do not use OSGi to obtain >>> the implementation class from a factory. There should be no runtime >>> dependency on the OSGi framework. >>> >>> Are there any good examples out there that I could try to emulate? >>> >>> If not, can anybody provide me with some advice? >>> >>> My thought is to have: >>> >>> 1. A public api package (for all cases) >>> 2. A private “factory” package (which for OSGi users would just be >>> private and ignored, and for non-OSGi users would be the part of the >>> library they would use to obtain the service class), and >>> 3. An “internal” package that includes an Activator (in an OSGi >>> environment this would provide the service implementation, for non-OSGi >>> users it would be ignored). >>> >>> >>> Thanks so much!! >>> >>> Cheers, >>> =David >>> >>> >>> _______________________________________________ >>> 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 > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
