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 API.
Cheers, Radu > On 3 Sep 2018, at 10:24, Stefan Seifert <[email protected]> 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] https://www.apress.com/de/book/9781430209737 > > > >> >> - 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 [mailto:[email protected]] >>>> Sent: Sunday, September 2, 2018 10:02 PM >>>> To: [email protected] >>>> Subject: [VOTE] Initial Release of Apache Sling Resource Filter version >>>> 1.0.0 >>>> >>>> Hi, >>>> >>>> We solved 1 issue in this release: >>>> https://issues.apache.org/jira/projects/SLING/versions/12343798 >>>> >>>> Staging repository: >>>> https://repository.apache.org/content/repositories/orgapachesling-1952/ >>>> >>>> You can use this UNIX script to download the release and verify the >>>> signatures: >>>> https://gitbox.apache.org/repos/asf?p=sling-tooling- >>>> release.git;a=blob;f=check_staged_release.sh;hb=HEAD >>>> >>>> Usage: >>>> sh check_staged_release.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 >>> >
