> I think it would be great if the role of each interface in the OSGi > Compendium could be explicitly documented, either with the bnd annotation or > at least some JavaDoc comment.
At OSGi, we use the javadoc tag @noimplement to mark provider implemented interfaces. Interfaces not marked @noimplement are consumer implemented interfaces. So, for example, in Config Admin, the ConfigurationAdmin interface is marked @noimplement while the ManagedService and ManagedServiceFactory interfaces are not. In the spec, you will see "No Implement Consumers of this API must not implement this interface" for @noimplement marked interfaces. In the html javadoc, you will see "Consumers of this API must not implement this interface" for @noimplement marked interfaces. -- 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 From: Martin Ždila <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 2013/01/16 11:51 Subject: Re: [osgi-dev] API consumer vs provider Sent by: [email protected] Thanks Neil. You've helped me a lot :-) On Wed, Jan 16, 2013 at 5:38 PM, Neil Bartlett <[email protected]> wrote: > Right, of course the bnd annotation is a hint to bnd and you cannot always > expect to find it on APIs. > > In the case of the Configuration Admin spec, implementing ManagedService or > ManagedServiceFactory does not make you a provider. You would have to > implement ConfigurationAdmin in order to be a provider. > > The rule of thumb is as follows: suppose a method were added to > ManagedServiceFactory... how many bundles would be broken as a result? The > answer is "lots" and therefore MSF is a consumer type. However if you added > a method to ConfigurationAdmin then only a very small number of bundles > would be broken; these are the providers of the Configuration Admin API, > e.g. org.apache.felix.configadmin and so on. > > I think it would be great if the role of each interface in the OSGi > Compendium could be explicitly documented, either with the bnd annotation or > at least some JavaDoc comment. > > Neil > > > On Wed, Jan 16, 2013 at 4:25 PM, Martin Ždila <[email protected]> wrote: >> >> Neil, thanks for the answer. >> >> Now how to find out whether ManagedServiceFactory is ProviderType or >> ConsumerType? It has no such annotation and I couldn't find out >> anything in the interface documentation. >> >> On Wed, Jan 16, 2013 at 5:14 PM, Neil Bartlett <[email protected]> >> wrote: >> > Very good question. This is why we distinguish between "provider >> > implemented" and "consumer implemented" interfaces. Usually to a >> > developer >> > the role of the interface is clear, as you have intuitively grasped: >> > interfaces that are merely callbacks or listeners are generally >> > "consumer >> > implemented". In bnd we have two annotations @ProviderType and >> > @ConsumerType >> > that we place on the interface that allows the tooling to detect the >> > role of >> > the interface and generate the correct import range. >> > >> > So the rule is, your bundle is a provider of the API if it implements >> > any of >> > the "provider implemented" types. Otherwise it is a consumer. >> > >> > Neil >> > >> > On Wed, Jan 16, 2013 at 2:58 PM, Martin Ždila <[email protected]> wrote: >> >> >> >> Hello >> >> >> >> How can I distinguish whether some bundle is API consumer or provider? >> >> >> >> I need it to specify correct Import-Package version range. >> >> >> >> Is the bundle automatically provider if it implements any interface >> >> from imported package, even interfaces like listeners and others that >> >> seems to be more consumer-like? >> >> >> >> I am asking because we are using Configuration Admin implementation of >> >> version 1.5 but we have many bundles that implements >> >> ManagedServiceFactory from 1.4. ManagedServiceFactory interface of 1.5 >> >> is compatible with 1.4 and 1.3, but if we use provider version range >> >> for our bundles then it forbids us to use them for both 1.4 and 1.5 >> >> implementation even they are interface-compatible. >> >> >> >> Thanks in advance >> >> Best regards >> >> >> >> -- >> >> Ing. Martin Ždila >> >> tel:+421-908-363-848 >> >> mailto:[email protected] >> >> http://www.zdila.sk/ >> >> >> >> _______________________________________________ >> >> OSGi Developer Mail List >> >> [email protected] >> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> > >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> >> -- >> Ing. Martin Ždila >> tel:+421-908-363-848 >> mailto:[email protected] >> http://www.zdila.sk/ >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev -- Ing. Martin Ždila tel:+421-908-363-848 mailto:[email protected] http://www.zdila.sk/ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
