Done now:
https://github.com/apache/sling-org-apache-sling-providertype-bnd-plugin
> On 1. Dec 2023, at 13:26, Stefan Seifert
> wrote:
>
>
>> We used different approaches for package and artifact names in
>> https://github.com/apache/sling-org-apache-sling-caconfig-bnd-
>> plugin/tree/master
> 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.
yes, that was my fault (i created both artifacts but in quite different points
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
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-apac
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
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 poli
