>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 >>
