Yes, Justin, that is correct.
Cohort A will get an update that will contain the new/updated bundles
and so becomes Cohort A' which will be similar to Cohort B in that
regard. However updates of Bundle C must still be compatible with the
Cohort A.
To go more into detail:
* Bundle A providing org.
Hi Dirk,
Possibly I misunderstood the invariants in your situation. Here's what I
understood:
* There's a set of installations with Bundle A (that exports org.foo) and
*not* Bundle B (that exports org.bar) -- let's call this Install Cohort A
* There's a set of installations with Bundle A and Bundl
Ok I understand, thanks.
Unfortunately, I cannot guarantee that my consumer Bundle C is only
used in installations that have all the other bundles installed yet,
due to backward compatibility reasons.
I will go for dynamic imports for now and once we drop support for the
older versions and suppor
The implementation of the resolver will be different depending on the OSGi
Framework implementation, so you're really getting into the weeds if you
start relying on those internals.
If one of your bundle's imports is optional, then by definition your bundle
has to work when that import is not wire
Thanks for the suggestion Justin.
What if I cannot guarantee that the Shim API Bundle exists on all
installations, same as Bundle B? That would mean the org.shim import
in Bundle C is optional again.
In fact I have a Bundle D already implementing both APIs from Bundle A
and B and registering the
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
6 matches
Mail list logo
