In general I'm fine with this, however as Justin noted adding "final "to some of the classes might break clients of Sling. Marking an interface as ConsumerType means also we shouldn't change it, right? (i'm fine with that, just clarifying)
Carsten 2013/8/5 Felix Meschberger <fmesc...@adobe.com> > 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 <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 > > -- Carsten Ziegeler cziege...@apache.org
