Bill Shannon wrote:
> 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?
>
It's *by design*. A bundle name is *not* similar to /Extension-Name/ of
an "installed optional package.". A bundle name (the corresponding
manifest entry is Bundle-SymbolicName) along with the bundle version
uniquely identifies a given bundle. If there are more than one jar files
that use same bundle name and version, then only one of them can be
installed irrespective of their contents.
>> 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?
Part of the problem is who decides what javax.persistence OSGi bundle's
interface should look like. So, they (OSGi) fall back on using package
names to specify dependencies. I have a feeling they assume that package
names are controlled by some specification somewhere, which is in fact
true to a large extent.
>
> > 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.
The previous comments applies here as well. Today, a bundle in OSGi is
an deployment artifact. Having a coarse-grained, development time
abstraction would certainly help, especially in cases where a set of
packages taken together defines the contract, e.g., javax.resource and
javax.resource.cci. I think that's where module in JDK 7 might prove
very useful.
Thanks,
Sahoo