Hi,

Richard S. Hall schrieb:
> We dynamically import * to avoid forcing all users of compendium to
> satisfy all dependencies to use it, because most of the time they are
> not needed for the contained service interfaces. However, in the cases
> where they are needed, it is problematic.

IIRC the official bundle jars als have DynamicImport-Package, but maybe
a bit more specific. I think we once had static imports which resulted
in the bundle jars being unusable due to required dependencies (see your
third point below).

> 
> Why do we provide these bundles at all? Originally, the OSGi JAR files
> were not bundles, so we needed something and did it ourselves. Now this
> is no longer the case, I believe.
> 
> It seems we need to figure out what we should do to address such issues
> in the future. I think there are three options:
> 
>   1. Stop providing these bundles altogether and just rely on the
>      official artifacts from the OSGi Alliance (I believe they are in a
>      maven repo somewhere).
>   2. Provide them with their full explicit dependencies (i.e., static
>      Import-Package declarations).
>   3. Divide them up into more reasonable chunks, since they lack
>      cohesion as bundles which makes managing their dependencies more
>      unreasonable (e.g., it sucks having to deploy a provider of
>      javax.microedition.io for org.osgi.service.io when you just want
>      to use logging).
> 
> At this point, I think the order of the options listed here is the order
> of my preference.

I would apply the same order, though I don't particularly like number 2
due to the "hard" dependencies, unless those are declared optional.

> 
> I talked to Tom Watson about this and he agrees, saying he thinks their
> bundles are a mistake and doesn't plan on updating them. His recommended
> approach for the future is to bundle the API with the implementations.
> 
> Sounds good to me, since that's what we do too. What do you guys think?

I am split on this. Consider a logging bundle which exports the OSGi Log
Service API. Almost all bundles will wire to that due to this. Then
updating the log bundle will cause massive rewiring....

I don't think, that this is really the intent. So while I agree, that
implementations should generally also export the respective official
OSGi API, we might still want to have a specific "OSGi API bundle".

Regards
Felix


> 
> -> richard
> 

Reply via email to