Hi Dirk, This is a possibly impractical suggestion in your context, but have you thought about modeling this as services? Something like:
Bundle A (ID: 200) - Export-Package: org.foo;version=1.0.0 Bundle B (ID: 210) - Import-Package: org.foo;version="[1.0,2)" - Export-Package: org.bar;version=1.0.0 Shim API Bundle: - Export-Package: org.shim;version=1.0.0 Shim for Bundle A Bundle - Import-Package: org.shim;version="[1.0.0,2)",org.foo;version="[1.0,2)" Shim for Bundle B Bundle - Import-Package: org.shim;version="[1.0.0,2)",org.bar;version="[1.0,2)" Bundle C - Import-Package: org.shim;version="[1.0.0,2)" The Shim API bundle exports a service interface that is implemented in both "Shim for Bundle A Bundle" and "Shim for Bundle B Bundle" (backed by the corresponding org.foo or org.bar API). The service in "Shim for Bundle B Bundle" has a higher service ranking. The service reference in Bundle C would (assuming it was properly set up) get one or the other. Regards, Justin On Thu, Oct 14, 2021 at 1:40 PM Dirk Rudolph <d...@apache.org> wrote: > Hi, > > tldr; is the order in which bundles get resolved predictable? > > We are facing issues with the usage of optional imports. Sometimes an > optionally imported package gets wired and sometimes it doesn't. > Refreshing the consuming bundle's package imports after startup always > works to get the wiring done right. > > Consider the following bundles: > > Bundle A (ID: 200) > - Export-Package: org.foo;version=1.0.0 > > Bundle B (ID: 210) > - Import-Package: org.foo;version="[1.0,2)" > - Export-Package: org.bar;version=1.0.0 > > Bundle C (ID: 500) > - Import-Package: > org.foo;version="[1.0,2)",org.bar;version="[1.0,2)";resolution:=optional > > All bundles have the same startlevel (20), in case it matters (?). > > Our use-case is that Bundle C used to use an API provided by Bundle A, > which got improved and extended into a new API provided by Bundle B. > Not all installations provide Bundle B, but all provide Bundle A. > Bundle C now prefers the optionally available API of Bundle B but > falls back to the API provided by Bundle A if Bundle B is not > available. > > I think the usage of optional imports is reasonable here, or are there > alternatives besides using dynamic imports? > > Thanks, > > - Dirk > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
