+1 Regards, Amit
-----Original Message----- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 05 August 2013 20:35 To: dev@sling.apache.org Subject: [DISCUSS] Consider implementors of Sling API 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
