Hi Felix, +1 to all of this. Out of curiosity, would adding the final keyword require a major version bump? It isn't backwards compatible, but is perhaps an interesting grey area.
Justin On Mon, Aug 5, 2013 at 11:04 AM, Felix Meschberger <fmesc...@adobe.com>wrote: > Hi all > > While working on SLING-2944 [1] it occurred to me that we do not currently > take good care to differentiate between interfaces to be implemented by a > single bundle (such as SlingHttpServletRequest) and interfaces which may be > implemented by multiple bundles to extend some functionality (such as > ResourceProvider). > > Also, we have a number of constant, helper, and utility type classes in > the Sling API, which we should not make available to extensibility. > > I have created SLING-2993 [2] and provided a patch to the Sling API such > that: > > * All classes intended for extension remain unchanged > * All classes not intended for extension are marked final > * All interfaces intended to be implemented by multiple bundles > (providers) are marked @ConsumerType > * All interfaces intended to be implemented by a single bundle are marked > as @ProviderType > > This change also requires to update the Maven Bundle Plugin version in the > Sling parent POM to 2.4.0. > > This change would prevent us from collateral damage such in the context of > SLING-2944 where the Servlet Resolver, Filesystem Resource Provider, and > Bundle Resource Provider bundles have to be updated just because the > ResourceResolverFactory API has been extended. > > WDYT ? > > Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-2944 > [2] https://issues.apache.org/jira/browse/SLING-2993
