On Mon, 2020-09-07 at 10:29 +0200, Oliver Lietz wrote: > On Thursday, August 27, 2020 9:58:47 AM CEST Robert Munteanu wrote: > > Hi Olli, > > Hi Robert, > > > I see you've been adding some SonarClud rules to skip to various > > modules. Could I ask you to briefly list the rules that you > > suppress > > and the reason? A page [1] would be great, and would help us be > > consistent about what rules we ignore. > > As mentioned at one of our hackathons at adaptTo() I'm not too happy > with > default rules in context of OSGi as they are harmful when followed > blindly. > See for example: > https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/15/ > commits/323b7d88141a07b7bb9331c2aa2949cf4704b911 (not blaming anyone > here, > just an example) > > I'm already collecting rules to break with examples and reasons and > will > compile a list.
That would be great. > > > Maybe at some point it would be possible to create a 'Sling' > > ruleset > > and ignore them altogether. > > Not sure if a custom ruleset can really help because it often depends > on > context, e.g. java:S1149 complains about Dictionary/Hashtable which > is in > general right but totally fine here: > https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-commons-crypto&issues=AW8ENya8oJs9k5IpsXLE&open=AW8ENya8oJs9k5IpsXLE > > Also I'm not too happy with cluttering the Sling code with > annotations to > suppress the warnings but I'm not familiar with writing rules (yet). > Would a rule which takes context (OSGi API) into account be possible > at all? Since the analysis is running on the SonarCloud platform, we don't have a way to inject custom rules [1]. I think what could work is filing an enhancement request for OSGi APIs so they are basically excluded from certains checks. We might want to run this over other communities ( e.g. Felix, OSGi-dev ) for more traction. Thanks, Robert [1]: https://community.sonarsource.com/t/create-custom-rules-for-c-in-sonarcloud/3634
