> Regarding 2 and 3 below, my point is that a client bundle should > declare whether it is consumer or provider of an imported package > (default consumer).
The definer of the API must declare that certain types are implemented by providers of the API and the other types are implemented by consumers of the API. Introspection of the bytecode of a bundle can determine whether the bundle implements a provider type or not. Thus the "client bundle" does not need to declare anything special. By virtue of what the bundle actually does (e.g. implement a provider type), tools can determine the role of the bundle. > With that knowledge, building a bundle that > consumes a package from another bundle should fail if the client > contains any implementations of provider-type interfaces. Well, yes. If you make a bundle declare his role regarding the package, you can detect errors. But requiring the bundle to declare the role is generally duplicate information since the bundle either does or does not implement a provider type from the package. > > If the client cannot declare consumer or provider role/policy, a > build cannot fail when a (consumer) client (by mistake) implements > both consumer and provider types. A bundle being able to declare its role against a package is a tool issue that is out of scope for type annotations. > > Switching between consumer and provider policy automatically based > on whether the client implements provider type interfaces is too > much automation in my view. Getting a provider policy instead of a > consumer policy unnoticed will introduce major problems later due to > not being able to upgrade bundles individually. And of course the converse is also a problem. That is why bytecode inspection + type marking provides the correct answer. > > Given the above, provider type becomes the obvious default, since it > really is the more restrictive one, clients can only implement a > provider type interface if they are declared as providers of the > containing package. I don't think this makes sense. Your argument can only work if all the types in the package are marked provider or consumer and the bundle declares it intended role for the package. If you have all that, then, of course, defaults are irrelevant! :-) Also, if your tool lets a bundle declare its role against the package (whose types are not marked provider or consumer), then the import range for the package can constrained by the declared role alone. And the default of a type in the package is irrelevant. > > Notice that changing an interface from provider to consumer type is > safe in a minor version (regardless of the above), since clients > build against the type when it was a provider type will be > incompatible (if they implement the type). The reverse is not true, > going from consumer to provider type will require a major version > update of the package. This again favors that provider type is the default. Changing a type from provider to consumer (or vice versa) indicates a serious design issue with the package that should be addressed with a major version bump or a new package name. > > Regarding the annotation indirection, defining the ability to use a > different annotation scheme in the spec could free us from problems > getting the consumer/provider type annotation right (plus this would > be the only osgi-dependency for most of our code). The dependency is a compile-time only dependency. So it is not too hard. And the compiled code is useful outside of OSGi since it has no runtime linkage to the OSGi API. A meta-annotation would only hide the broad impact of a crazy change such as moving from consumer to provider. Finally, it is really not a meta-annotation. It is a type annotation. It says something about the type and nothing about an annotation. > In our case, we > do have a hard rule that certain annotations dictate consumer type. > The easiest way to enforce this would be to declare it on our > annotation(s) so that developers only need to apply the one > annotation, not both. The other way we have is to add a compilation > check ourselves that validates that the rule is not broken. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
