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 <sseif...@pro-vision.de>: > > 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:konra...@gmx.de] >> Sent: Wednesday, March 1, 2017 9:03 AM >> To: dev@sling.apache.org >> 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 >> > >
