Sahoo wrote:
>> I would expect the dependency to be in terms of the module.
> I beg to differ. Specifying dependency using module name is appropriate
> if the module boundary is standardised and module name does not specify
> the name of an implementation. Since neither of the above is true,
> depending on module severely affects substitutability at runtime. Here
Is this not true *by design* in OSGi, or is it not true *by convention*.
Does OSGi require bundle names to uniquely name the implementation, or
is that just what everyone does?
> is an example:
>
> jpa-provider-A needs javax.persistence.* packages.
> jpa-provider-B also needs javax.persistence.* packages.
>
> Both want to be self sufficient, so they both have their own modules
> containing javax.persistence classes.
Why wouldn't they both reference a common javax.persistence bundle,
which they could both package with their products?
> Let's call them jpa-interface-A
> and jpa-interface-B respectively. If they use Require-Bundle, then when
> both jpa-provider-A and B are simultaneously used, javax.persistence
> classes would be loaded twice making any kind of interaction between the
> two providers using the javax.persistence classes impossible. Let's
> suppose an application uses both the providers simultaneously; it reads
> using provider-A and writes using provider-B. It's only going to get
> ClassCastException, isn't it?
>
> On the other hand, Import-Package does not have any such issue.
Assuming jpa-provider-B can work with the jpa-interface-A module.
If jpa-interface-A and jpa-interface-B have the same content, they
should've had the same bundle name. If they have different content,
there's no reason to believe you can mix and match providers with
interface bundles.