Create rule S6862: Beans in "@configuration" class should have differ…

…ent names

rules/S6862/java/metadata.json

@@ -1,25 +1,24 @@
 {
-  "title": "FIXME",
-  "type": "CODE_SMELL",
+  "title": "Beans in \"@Configuration\" class should have different names",
+  "type": "BUG",
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
   "tags": [
+    "spring"
   ],
   "defaultSeverity": "Major",
   "ruleSpecification": "RSPEC-6862",
   "sqKey": "S6862",
-  "scope": "All",
+  "scope": "Main",
   "defaultQualityProfiles": ["Sonar way"],
   "quickfix": "unknown",
   "code": {
     "impacts": {
-      "MAINTAINABILITY": "HIGH",
-      "RELIABILITY": "MEDIUM",
-      "SECURITY": "LOW"
+      "RELIABILITY": "MEDIUM"
     },
-    "attribute": "CONVENTIONAL"
+    "attribute": "CLEAR"
   }
 }

rules/S6862/java/rule.adoc

@@ -1,44 +1,54 @@
-FIXME: add a description
-
-// If you want to factorize the description uncomment the following line and create the file.
-//include::../description.adoc[]
-
 == Why is this an issue?
 
-FIXME: remove the unused optional headers (that are commented out)
-
-//=== What is the potential impact?
+Naming conventions play a crucial role in maintaining code clarity and readability.
+In Spring configurations, the uniqueness of bean names is vital to avoid confusion for both developers and the Spring Context.
+When two beans share the same name within a configuration, it becomes challenging for a reader to discern which bean is being referred to, leading to potential misunderstandings and errors.
 
 == How to fix it
-//== How to fix it in FRAMEWORK NAME
+
+To address this issue, ensure each bean within a configuration has a distinct and meaningful name.
+Choose names that accurately represent the purpose or functionality of the bean, making it easier for developers to understand the role of each component.
 
 === Code examples
 
 ==== Noncompliant code example
 
-[source,text,diff-id=1,diff-type=noncompliant]
+[source,java,diff-id=1,diff-type=noncompliant]
 ----
-FIXME
+@Configuration
+class Config {
+  @Bean
+  public User user() {
+    return currentUser();
+  }
+  @Bean
+  public User user(AuthService auth) { // Noncompliant
+    return auth.user();
+  }
+}
 ----
 
 ==== Compliant solution
 
-[source,text,diff-id=1,diff-type=compliant]
+[source,java,diff-id=1,diff-type=compliant]
 ----
-FIXME
+@Configuration
+class Config {
+  @Bean
+  public User user() {
+    return currentUser();
+  }
+  @Bean
+  public User userFromAuth(AuthService auth) {
+    return auth.user();
+  }
+}
 ----
 
-//=== How does this work?
-
-//=== Pitfalls
-
-//=== Going the extra mile
+== Resources
 
+=== Documentation
 
-//== Resources
-//=== Documentation
-//=== Articles & blog posts
-//=== Conference presentations
-//=== Standards
-//=== External coding guidelines
-//=== Benchmarks
+* https://docs.spring.io/spring-framework/reference/core/beans/java/basic-concepts.html[Spring IO - Basic concepts: @Bean and @Configuration]
+* https://docs.spring.io/spring-framework/reference/core/beans/java/configuration-annotation.html[Spring IO - Using the @Configuration annotation]
+* https://docs.spring.io/spring-framework/reference/core/beans/java/bean-annotation.html[Spring IO - Using the @Bean annotation]