Sahoo wrote:
> Bill Shannon wrote:
>> Sahoo wrote:
>>> The attached file lists package names that are split across multiple
>>> modules in GFv3 workspace. This list may not be totally accurate, so
>>> use it as an indicator only. Module owners are requested to ensure
>>> that each package is defined by one runtime module only. This is
>>> needed so that we can start using *Import-Package* manifest headers
>>> to specify dependencies instead of using *Require-Bundle*.
>>
>> What's the reason for making that change? Is that the OSGi preferred
>> approach?
>>
> Yes, that's the preferred approach in OSGi.
I'll take your word for that. It certainly seems more natural to Java
programmers. But...
> Some of the issues with
> Require-Bundle are given below:
> a) difficult to replace an implementation with another.
Wouldn't multiple implementations all use the same bundle name,
describing the *API* they export? If bundle names describe the
implementation, then I agree with you.
Maybe the problem is exactly that - that bundle names are names
of the implementation artifact, but package names are names of the
API?
> b) dependencies of a bundle is not clear - not all of the exported
> packages of a bundle may be required by the requiring bundle.
I think "bundle" or "module" is a higher-level concept than "package".
The fact that a module contains multiple packages shouldn't be an issue.
I would expect the dependency to be in terms of the module.
> c) difficult to refactor a bundle - again for above mentioned reason.
It does depend on you getting the module boundaries correct to begin with.
> d) can lead to split-packages where in classes from same package are
> loaded from different bundles. Since each bundle has a different class
> loader, it can lead to access violation while using "package protected"
> symbols.
Split packages are clearly bad. It's unfortunate that OSGi supports them
at all.