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
