sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radu Cotescu <>
Subject Re: [VOTE] Initial Release of Apache Sling Resource Filter version 1.0.0
Date Mon, 03 Sep 2018 09:34:46 GMT
Hi Jason,

I strongly support Stefan’s observations here regarding the @ProvideType / @ConsumerType
annotations. Omitting them will only bring problems down the road for the consumers of this


> On 3 Sep 2018, at 10:24, Stefan Seifert <> wrote:
>> My understanding of the ConsumerType/ProviderType is that it's a
>> ConsumerType if the object  is meant to be consumed and a ProviderType if
>> it's meant to be implemented by another bundle to add or extend the
>> functionality. Along the lines of ProviderType ~= Service Provider
>> Interface.
>> These are meant to be consumed.
> ConsumerType means you expect other bundles to implement the interfaces themselves, or
extend/subclass classes you provide. in this case the bnd baseline check is much more strict,
it's e.g. not possible to add a new method to the interface without raising the major version
of the package because it may break with code using it.
> but i assume this is not the case here, because the interface is meant to be implemented
by the bundle itself, so ProviderType should be the correct annotation. provider means here
the interface is provided for usage, but not for implementing it.
>> As for marking classes final, I don't mark a class final unless there is a
>> clear need to mark the class final. My lack of understanding someone else's
>> use case for extending one of my classes is not sufficient enough reason
>> for me to do that.
> keep in mind that once we publish the API we cannot change it (without breaking compatibility
by raising the major version of the package). if you leave the classes that are part of the
API non-final they may be extended by using bundles, and if you expect this you should put
ConsumerType to it, leading to much more strict baseline checks, making it difficult to extend
them later. this was the learning it took from [1]. but if you put at least the ProviderType
annotation on the class it's clear it's not intended to be subclasses (but still technically
possible). it's easy to make a class non-final later, but not the reverse without breaking
the baseline compatibility check.
> stefan
> [1]
>> - Jason
>> On Sun, Sep 2, 2018, at 5:24 PM, Stefan Seifert wrote:
>>> hello jason.
>>> one last formal comment on the API of this module (sorry for coming up
>>> with it so late):
>>> - the API classes/interfaces should be annotated with the OSGi
>>> ProviderType/ConsumerType annotations
>>> - it looks for me they all should be applied with ProviderType
>>> - perhaps the classes ResourceFilterStream and ResourceStream should be
>>> declared final, unless they are explicitly designed for extension by
>>> subclassing
>>> stefan
>>>> -----Original Message-----
>>>> From: Jason E Bailey []
>>>> Sent: Sunday, September 2, 2018 10:02 PM
>>>> To:
>>>> Subject: [VOTE] Initial Release of Apache Sling Resource Filter version
>>>> 1.0.0
>>>> Hi,
>>>> We solved 1 issue in this release:
>>>> Staging repository:
>>>> You can use this UNIX script to download the release and verify the
>>>> signatures:
>>>> release.git;a=blob;;hb=HEAD
>>>> Usage:
>>>> sh 1952 /tmp/sling-staging
>>>> Please vote to approve this release:
>>>> [ ] +1 Approve the release
>>>> [ ]  0 Don't care
>>>> [ ] -1 Don't release, because ...
>>>> This majority vote is open for at least 72 hours.
>>>> - Jason

View raw message