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]> 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] > 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
