bndtools
Analyzer.findProvidedPackages only considers implemented provider interfaces but not extended provider classes
The ProviderType annotation may be applied to classes, interfaces and packages. While for interfaces the relation which needs to be checked is the "implements" relation, for classes it is the "extends" relation. But in https://github.com/bndtools/bnd/blob/d06df066f402f1433b70c51f568c40a444b4518d/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L2153 only the interfaces being implemented are checked if they are a provider type. The super class (i.e. the "extension" relation) is not considered. That may lead to incorrect import-package version ranges.
I think you ran into my very old dislike for inheritance in API, especially inheritance to a class in another package ... begging for problems.
This is very hot code so I am a bit hesitant to just add the super class, but it does seem to make sense for the poor souls having to live with heavy inheritance based APIs.
@bjhargrave as the only person I trust in this topic, can you take a look and tell me if you see problems?
It should probably also include the super class in the result if the super class is ProviderType. But it basically almost never makes sense to mark a non-interface class as ProviderType unless the class has protected methods which only a subclass could invoke.
Also, I think there is an issue in
https://github.com/bndtools/bnd/blob/4d1c6b08957f853691d906113414d657db91e6ea/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L2173-L2186
since it does not appear to handle the case where the package containing the type is marked ProviderType.
since it does not appear to handle the case where the package containing the type is marked ProviderType. Interesting ... I did not know we support the package for the ProviderType ...
I did not know we support the package for the ProviderType ...
https://github.com/osgi/bugzilla-archive/issues/2774
osgi/bugzilla-archive#2774
Ha! I love that this bugzilla archive is still useful.
But it basically almost never makes sense to mark a non-interface class as ProviderType unless the class has protected methods which only a subclass could invoke.
I think often these are abstract classes extending from an interface being provided centrally, from which different provider bundles just inherit their own implementation.
... inherit their own implementation
And that is why it should never be API ... Fine for provider bundles, but in API it sucks majorly.
Just to have a reference: This seems to be related to this issue here: https://github.com/osgi/osgi/issues/643
@juergen-albert Could be related but https://github.com/osgi/osgi/issues/643 is broader as it is about multiple levels of inheritance as well.
@tbitonti any progress? If you're having a hard time let me know. If necessary I can take this over.
@tbitonti if you can't work on this, please unassign yourself. It has been open for two months now and I want this closed.