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
