Thanks, Ray. I like the simple/complex and must-implement/optionally-implement axes, as both are probably good indicators of whether or not a consumer (in the generic sense) is likely to be impacted by minor-version changes in a provider (generic sense).
I'll have another look at my interfaces & classes with these in mind.... Cheers, Jeff. From: Raymond Auge <[email protected]<mailto:[email protected]>> Reply-To: OSGi Developer Mail List <[email protected]<mailto:[email protected]>> Date: Friday 10 October 2014 17:02 To: OSGi Developer Mail List <[email protected]<mailto:[email protected]>> Subject: Re: [osgi-dev] Usage of ProviderType and ConsumerType I would personally mark your abstract classes @ProviderType since the only thing you want people to do with this is extend them, which is safe for them as long as you don't delete or change signatures on methods or public members. Adding is binary safe. For the rest I would break into two groups: A) Interfaces which any client must implement in order to use the lib (including the extension parts) - @ConsumerType B) anything that must be implemented to deliver the full functionality of the lib - @ProviderType In my experience, complex things to implement are typically @ProviderType, simple things to implement are @ConsumerType. This definition fits rather well considering something like the event listener model. Typically those are very simple interfaces to implement, and many consumers benefit from implementing them. However, implementing the part of the story which invokes the event listeners might also be implementable, but FAR less frequently, and typically by only experts who are "providing" an implementation of the feature. HTH - Ray On Fri, Oct 10, 2014 at 11:33 AM, Jeff Young <[email protected]<mailto:[email protected]>> wrote: I've got an API package that allows 3rd-parties to extend part of a system. Most of the interfaces in it are marked ConsumerType. (There are a few that are for singleton "managers" of the extensions, and those are marked ProviderType.) There is also a "common" package that provides some classes to help in building such extensions. There are three primary types of things in the "common" package: * Abstract Classes. I have these marked ConsumerType. * Default Implementation Classes. Some implementations will use these as-is, while others will use them as base classes, and still others won't use them at all. In the base-class case they're pretty similar to the abstract classes above. But since they all implement interfaces in the "api" package, and those are marked ConsumerType, I currently don't have these classes marked at all. (Then again, by the same logic I don't need to mark the abstract classes above either.) * POJOs. These are mostly classes which represent common collections of parameters or common collections of return information (such as a query result). I currently don't have these marked at all. Is this what I want, or should I be marking some of these differently? Thanks, Jeff. _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev -- Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect Liferay, Inc.<http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
