I made org.apache.sling.validation.SlingValidationException a consumer type (but not final, because for some validators you might want to derive your own class from that Exception).
If it would be a provider type, every bundle which derives from SlingValidationException would have an import-package header pointing to org.apache.sling.validation with a version range [==,=+)! Therefore this bundle will no longer resolve, if e.g. a new method is added to ValidationService. Making it a consumer type resolves this issue. Both org.apache.sling.validation.spi.DefaultValidationFailure and org.apache.sling.validation.spi.DefaultValidationResult are now provider types and final. I applied the changes in http://svn.apache.org/r1785825. Konrad > On 6 Mar 2017, at 22:40, Stefan Seifert <[email protected]> wrote: > > when this three classes are not intended to be derived from we should > definitely declare them final to be on the safe side. > > stefan > > >> -----Original Message----- >> From: Konrad Windszus [mailto:[email protected]] >> Sent: Monday, March 6, 2017 8:09 PM >> To: [email protected] >> Subject: Re: Time for a Sling Validation 1.0.0 release >> >> Hi Stefan, thanks for your comments. >> IIRC the provider and consumer type annotations only have an influence if >> you derive from/implement those. >> I would for now be in favor of making all those final (i.e. prevent to >> derive from those classes). If there really is a need to implement your own >> ValidationFailure or ValidationResult you should rather start from scratch. >> >> WDYT? >> Konrad >> >>> Am 06.03.2017 um 19:06 schrieb Stefan Seifert <[email protected]>: >>> >>> i did not had the time to really think into the API itself, but from a >> formal perspective I think for those 3 classes it would be good to >> explicitly add the corresponding @ProviderType or @ConsumerType annotation: >>> >>> org.apache.sling.validation.SlingValidationException -> @ProviderType, >> and maybe make it final? >>> org.apache.sling.validation.spi.DefaultValidationFailure -> @ConsumerType >> ? >>> org.apache.sling.validation.spi.DefaultValidationResult -> @ConsumerType >> ? >>> >>> stefan >>> >>> >>>> -----Original Message----- >>>> From: Konrad Windszus [mailto:[email protected]] >>>> Sent: Wednesday, March 1, 2017 9:03 AM >>>> To: [email protected] >>>> Subject: Time for a Sling Validation 1.0.0 release >>>> >>>> Hi everyone, >>>> I think it is time now for a first release of Sling Validation. I used >> it >>>> in several projects already productively and fixed a lot of bugs and >>>> refactored the interfaces from the initial proposal from Radu quite a >> bit >>>> (44 issues have been resolved since then, >>>> https://issues.apache.org/jira/browse/SLING/fixforversion/12328980). >>>> It would be good if everyone who could afford some time could quickly >>>> cross-check the API at >>>> >> https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/ap >>>> i. >>>> All concerns being raised in a previous review >>>> (https://issues.apache.org/jira/browse/SLING-4027) have been addressed >>>> meanwhile. >>>> >>>> Thanks, >>>> Konrad >>>> >>> >>> >> > >
