Hi Am 06.08.2013 um 08:03 schrieb Carsten Ziegeler:
> 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) Yes. The implication of @ConsumerType is that any change requires a major version increment in the package export. This is a burden to us API designers but helps consumers ;-) Regards Felix > > 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
