+1
On Mon, Aug 5, 2013 at 11:18 AM, Amit.. Gupta. <amitg...@adobe.com> wrote: > +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 >
