Update rules metadata

Author: irina-batinic-sonarsource

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S3749.html

@@ -1,9 +1,10 @@
 <h2>Why is this an issue?</h2>
-<p>Spring <code>@Component</code>, <code>@Controller</code>, <code>@Service</code>, and <code>@Repository</code> classes are singletons by default,
-meaning only one instance of the class is ever instantiated in the application. Typically such a class might have a few <code>static</code> members,
-such as a logger, but all non-<code>static</code> members should be managed by Spring.</p>
-<p>This rule raises an issue when a singleton <code>@Component</code>, <code>@Controller</code>, <code>@Service</code>, or <code>@Repository</code>,
-not annotated with <code>@ConfigurationProperties</code>, has non-<code>static</code> members that are not annotated with one of:</p>
+<p>Spring <code>@Component</code>, <code>@Controller</code>, <code>@RestController</code>,<code>@Service</code>, and <code>@Repository</code> classes
+are singletons by default, meaning only one instance of the class is ever instantiated in the application. Typically such a class might have a few
+<code>static</code> members, such as a logger, but all non-<code>static</code> members should be managed by Spring.</p>
+<p>This rule raises an issue when a singleton <code>@Component</code>, <code>@Controller</code>, <code>@RestController</code>, <code>@Service</code>,
+or <code>@Repository</code>, not annotated with <code>@ConfigurationProperties</code>, has non-<code>static</code> members that are not annotated with
+one of:</p>
 <ul>
   <li> <code>org.springframework.beans.factory.annotation.Autowired</code> </li>
   <li> <code>org.springframework.beans.factory.annotation.Value</code> </li>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4551.html

@@ -37,7 +37,6 @@ <h3>Compliant solution</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://www.javaworld.com/article/2074292/core-java/use-----or-----to-compare-java-enums.html">Use == (or !=) to Compare Java
-  Enums</a> </li>
+  <li> <a href="https://www.infoworld.com/article/2074292/use-----or-----to-compare-java-enums.html">Use == (or !=) to Compare Java Enums</a> </li>
 </ul>
 

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4792.html

@@ -1,3 +1,4 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
 <p>Configuring loggers is security-sensitive. It has led in the past to the following vulnerabilities:</p>
 <ul>
   <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0285">CVE-2018-0285</a> </li>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4792.json

@@ -7,10 +7,8 @@
     },
     "attribute": "CONVENTIONAL"
   },
-  "status": "ready",
-  "tags": [
-    "cwe"
-  ],
+  "status": "deprecated",
+  "tags": [],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-4792",
   "sqKey": "S4792",

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S5973.html

@@ -1,9 +1,9 @@
 <h2>Why is this an issue?</h2>
 <p>Unstable / flaky tests are tests which sometimes pass and sometimes fail, without any code change. Obviously, they slow down developments when
-engineers have to rerun failed tests. However the real problem is that you can’t completely trust these tests, they might fail for many different
+developers have to rerun failed tests. However, the real problem is that you can’t completely trust these tests, they might fail for many different
 reasons and you don’t know if any of them will happen in production.</p>
-<p>Some tools, such as TestNG, enable developers to automatically retry flaky tests. This might be ok as a temporary solution, but it should
-definitely be fixed. The more flaky tests you add, the more chances there are for a bug to arrive in production.</p>
+<p>Some tools, such as TestNG, enable developers to automatically retry flaky tests. This might be acceptable as a temporary solution, but it should
+eventually be fixed. The more flaky tests you add, the more chances there are for a bug to arrive in production.</p>
 <p>This rule raises an issue when the annotation <code>org.testng.annotations.Test</code> is given a <code>successPercentage</code> argument with a
 value lower than <code>100</code>.</p>
 <h3>Noncompliant code example</h3>
@@ -18,8 +18,9 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://testng.org/doc/documentation-main.html#annotations">TestNG documentation - Annotations</a> </li>
-  <li> <a href="https://engineering.atspotify.com/2019/11/18/test-flakiness-methods-for-identifying-and-dealing-with-flaky-tests/">Test Flakiness -
-  Methods for identifying and dealing with flaky tests</a> </li>
+  <li> TestNG documentation - <a href="https://testng.org/doc/documentation-main.html#annotations">Annotations</a> </li>
+  <li> Spotify Engineering - <a
+  href="https://engineering.atspotify.com/2019/11/18/test-flakiness-methods-for-identifying-and-dealing-with-flaky-tests/">Test Flakiness - Methods
+  for identifying and dealing with flaky tests</a> </li>
 </ul>
 

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S5973.json

@@ -3,7 +3,8 @@
   "type": "CODE_SMELL",
   "code": {
     "impacts": {
-      "MAINTAINABILITY": "MEDIUM"
+      "MAINTAINABILITY": "MEDIUM",
+      "RELIABILITY": "MEDIUM"
     },
     "attribute": "TESTED"
   },

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json

@@ -342,7 +342,6 @@
     "S4719",
     "S4738",
     "S4790",
-    "S4792",
     "S4830",
     "S4838",
     "S4925",

sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "JAVA"
   ],
-  "latest-update": "2023-11-24T15:20:38.530699Z",
+  "latest-update": "2023-12-18T09:12:31.787089Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": false