> I agree the whiteboard pattern requires a consumer type and I am > aware of that the pattern is widely used in OSGi compendium. > However, in the products I have been working on, only handful times > this pattern or listener pattern were used. There were thousands > thousands interfaces declared though. > > For your 2nd point, based on my previous observation, the consumer > type interfaces are not common. The aggregation scenario is not > common either.
Data? Anecdotal stories do not really count. And besides, from a spec point of view, the spec should be correct. Tools, like the aries versioning tool, are free to make decisions that "help" the developer even when those decisions are sometimes wrong. > As a side point, I think when those annotations are > available, we should set a best practice (such as splitting provider > type interfaces from consumer type interfaces so that they are in > two packages. The package version management can be fine grained.) This was discussed and I am convinced this is not a best practice. Splitting into packages just explodes the number of packages. Both consumers and provider will probably need to import both packages. The two packages likely have a uses relationships. You still need some way to tell tool which package is the provider role and which is the consumer role. Any version bump to the consumer package will necessitate a version bump to the provider package. So this does not provide any value to anyone as far as I can see. It just adds unnecessary complication. > This OSGi annoation rfc sets its default value based on risk factor. > If the consumers of the annoations spec accept the risk being low, > what is the point to fighting instead of collecting votes. You are one consumer of the spec. I don't think there is consensus across all spec consumers of your opinion. And the aries versioning tool is free to do what it wishes. Finally, the number of people who believe a thing does not make that thing true. -- 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
