Thanks for taking the time to spell that out for me :) For some reason I have problems with those Annotations, and your explanation is better then most I find online.
- Jason On Mon, Sep 3, 2018, at 4:24 AM, 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] 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 > >> >
