It turned out that such a check should be done before (outside Feature Analysers). There is now a Bnd plugin for achieving the same (i.e. check for extensions/implementations of provider types) in https://github.com/apache/sling-whiteboard/tree/provider-type-check-bnd-plugin.
As I would like to release it soon, I would propose to create a dedicated repository for it at sling-org-apache-sling-providertype-bnd-plugin (similar to https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin). We used different approaches for package and artifact names in https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin/tree/master and https://github.com/apache/sling-org-apache-sling-bnd-models. I would propose to follow the naming of https://github.com/apache/sling-org-apache-sling-caconfig-bnd-plugin with regards to repository, package and artifact name. WDYT? Konrad > On 9. Oct 2023, at 11:57, Konrad Windszus <[email protected]> wrote: > > Hi, > In the context of https://issues.apache.org/jira/browse/SLING-12026 I created > a new module for Feature Analysers in the Sling Whiteboard in > https://github.com/apache/sling-whiteboard/tree/feature-analyzer-for-classes. > I would suggest to move that to a dedicated repo with name > "sling-org-apache-sling-feature-analyser-classes”. > Please respond here if you have any objections. > Right now this module only contains a single analyser task for checking for > implementation/extension of provider types, but in the future there may be > other checks which might need to inspect classes (and not only bundle > manifest headers or feature descriptors). > > Konrad > > >> On 19. Sep 2023, at 08:28, Carsten Ziegeler <[email protected]> wrote: >> >> I don't see any concern with using asm. However, the analyser bundle has >> already quiet a few dependencies (mainly due to the native support for >> content packages). >> So maybe we can add such an analyser in a separate module or at least make >> the dependencies optional? >> >> I think it would be great to have the content package dependencies optional >> as well. But that's of course a different issue. >> >> Regards >> Carsten >> >> On 18.09.2023 16:28, Konrad Windszus wrote: >>> Hi, >>> In the context of https://issues.apache.org/jira/browse/SLING-12026 I would >>> need to parse Java class files to inspect them (on a high level only, i.e. >>> check for implemented interfaces). >>> I would like to use ASM for that: https://asm.ow2.io/. >>> Its license is BSD which is compatible with ASF policies: >>> https://www.apache.org/legal/resolved.html#category-a >>> The library itself is pretty small (120 KB). >>> Is there any concern with adding that dependency to >>> https://github.com/apache/sling-org-apache-sling-feature-analyser in order >>> to implement such an analyser (and potentially more like it in the future) >>> or is there a recommendation for any other library? >>> I know that simple parsing should be feasible with a JDK provided library >>> (https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/util/JavacTask.html) >>> but its API is quite complex… >>> Any feedback would be highly appreciated. >>> Thanks, >>> Konrad >> >> -- >> Carsten Ziegeler >> Adobe >> [email protected] >
