sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Windszus <konra...@gmx.de>
Subject Re: Time for a Sling Validation 1.0.0 release
Date Tue, 07 Mar 2017 10:55:40 GMT
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 <sseifert@pro-vision.de> 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:konrad_w@gmx.de]
>> Sent: Monday, March 6, 2017 8:09 PM
>> To: dev@sling.apache.org
>> 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 <sseifert@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:konrad_w@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
>>>> 
>>> 
>>> 
>> 
> 
> 


Mime
View raw message