Hi Am 05.08.2013 um 19:48 schrieb Justin Edelson:
> 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. Yes, technically, this is binary incompatible because existing extensions will fail to load. An option would be to omit the final qualifier but add JavaDoc indicating extension is not intended. Regards Felix > > Justin > > On Mon, Aug 5, 2013 at 11:04 AM, Felix Meschberger <[email protected]>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
