Simplify XML modelling for the current cursor rules (#131)

Create all XML files from the .MDC
Created a XSD from the modeling phase
Created a XSL from the modelling phase
Improved tests

Author: jabrena

.cursor/rules/100-java-checklist-guide.mdc

@@ -5,19 +5,17 @@ alwaysApply: false
 ---
 # Create a Checklist with all Java steps to use with cursor rules for Java
 
-## System prompt characterization
+## Role
 
-Role definition: You are a Senior software engineer with extensive experience in Java programming language and technical documentation
+You are a Senior software engineer with extensive experience in Java programming language and technical documentation
 
-## Description
+## Instructions for AI
 
 Your task is to create a comprehensive step-by-step guide that follows the exact format and structure defined in the embedded template below.
 
-## Instructions for AI
-
-Create a markdown file named `JAVA-DEVELOPMENT-GUIDE.md` with the following exact structure: [java-checklist-template.md](mdc:.cursor/rules/templates/java-checklist-template.md)
+Create a markdown file named `CURSOR-RULES-JAVA.md` with the following exact structure: [java-checklist-template.md](mdc:.cursor/rules/templates/java-checklist-template.md)
 
-### Restrictions
+## Restrictions
 
 **MANDATORY REQUIREMENT**: Follow the embedded template EXACTLY - do not add, remove, or modify any steps, sections, or cursor rules that are not explicitly shown in the template. ### What NOT to Include:
 
@@ -28,7 +26,6 @@ Create a markdown file named `JAVA-DEVELOPMENT-GUIDE.md` with the following exac
 - **ONLY** use the exact wording and structure from the template
 - If a cursor rule exists in the workspace but is not in the template, **DO NOT** include it
 
-
 ## Output Requirements
 
 - Generate the complete markdown file following the embedded template exactly

.cursor/rules/110-java-maven-best-practices.mdc

@@ -5,25 +5,27 @@ alwaysApply: false
 ---
 # Maven Best Practices
 
-## System prompt characterization
+## Role
 
-Role definition: You are a Senior software engineer with extensive experience in Java software development
+You are a Senior software engineer with extensive experience in Java software development
 
-## Description
+## Instructions for AI
 
-Effective Maven usage involves robust dependency management via `<dependencyManagement>` and BOMs, adherence to the standard directory layout, and centralized plugin management. Build profiles should be used for environment-specific configurations. POMs must be kept readable and maintainable with logical structure and properties for versions. Custom repositories should be declared explicitly and their use minimized, preferably managed via a central repository manager.
+Update the pom.xml based on the following rules about Maven best practices.
 
-## Table of contents
+## Examples
 
-- Rule 1: Effective Dependency Management
-- Rule 2: Standard Directory Layout
-- Rule 3: Plugin Management and Configuration
-- Rule 4: Use Build Profiles for Environment-Specific Configurations
-- Rule 5: Keep POMs Readable and Maintainable
-- Rule 6: Manage Repositories Explicitly
-- Rule 7: Centralize Version Management with Properties
+### Table of contents
 
-## Rule 1: Effective Dependency Management
+- Example 1: Effective Dependency Management
+- Example 2: Standard Directory Layout
+- Example 3: Plugin Management and Configuration
+- Example 4: Use Build Profiles for Environment-Specific Configurations
+- Example 5: Keep POMs Readable and Maintainable
+- Example 6: Manage Repositories Explicitly
+- Example 7: Centralize Version Management with Properties
+
+### Example 1: Effective Dependency Management
 
 Title: Manage Dependencies Effectively using `dependencyManagement` and BOMs
 Description: Use the `<dependencyManagement>` section in parent POMs or import Bill of Materials (BOMs) to centralize and control dependency versions. This helps avoid version conflicts and ensures consistency across multi-module projects. Avoid hardcoding versions directly in `<dependencies>` when managed elsewhere.
@@ -92,9 +94,10 @@ Description: Use the `<dependencyManagement>` section in parent POMs or import B
     </dependency>
   </dependencies>
 </project>
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
 ```xml
 <!-- Child POM hardcoding versions -->
@@ -118,16 +121,17 @@ Description: Use the `<dependencyManagement>` section in parent POMs or import B
     </dependency>
   </dependencies>
 </project>
+
 ```
 
-## Rule 2: Standard Directory Layout
+### Example 2: Standard Directory Layout
 
 Title: Adhere to the Standard Directory Layout
 Description: Follow Maven's convention for directory structure (`src/main/java`, `src/main/resources`, `src/test/java`, `src/test/resources`, etc.). This makes projects easier to understand and build, as Maven relies on these defaults.
 
 **Good example:**
 
-```
+```text
 my-app/
 ├── pom.xml
 └── src/
@@ -141,11 +145,12 @@ my-app/
         │   └── com/example/myapp/AppTest.java
         └── resources/
             └── test-data.xml
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
-```
+```text
 my-app/
 ├── pom.xml
 ├── sources/  <!-- Non-standard -->
@@ -155,9 +160,10 @@ my-app/
 └── tests/    <!-- Non-standard -->
     └── com/example/myapp/AppTest.java
 <!-- This would require explicit configuration in pom.xml to specify source/resource directories -->
+
 ```
 
-## Rule 3: Plugin Management and Configuration
+### Example 3: Plugin Management and Configuration
 
 Title: Manage Plugin Versions and Configurations Centrally
 Description: Use `<pluginManagement>` in a parent POM to define plugin versions and common configurations. Child POMs can then use the plugins without specifying versions, ensuring consistency. Override configurations in child POMs only when necessary.
@@ -198,9 +204,10 @@ Description: Use `<pluginManagement>` in a parent POM to define plugin versions
     </plugins>
   </build>
 </project>
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
 ```xml
 <!-- Child POM -->
@@ -220,9 +227,10 @@ Description: Use `<pluginManagement>` in a parent POM to define plugin versions
     </plugins>
   </build>
 </project>
+
 ```
 
-## Rule 4: Use Build Profiles for Environment-Specific Configurations
+### Example 4: Use Build Profiles for Environment-Specific Configurations
 
 Title: Employ Build Profiles for Environment-Specific Settings
 Description: Use Maven profiles to customize build settings for different environments (e.g., dev, test, prod) or other conditional scenarios. This can include different dependencies, plugin configurations, or properties. Activate profiles via command line, OS, JDK, or file presence.
@@ -272,9 +280,10 @@ Description: Use Maven profiles to customize build settings for different enviro
   </profiles>
 </project>
 <!-- Activation: mvn clean install -P prod -->
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
 ```xml
 <!-- Commented out sections for different environments -->
@@ -285,9 +294,10 @@ Description: Use Maven profiles to customize build settings for different enviro
     <database.url>jdbc:postgresql://prodserver/mydb</database.url> <!-- Manually switch by commenting/uncommenting -->
   </properties>
 </project>
+
 ```
 
-## Rule 5: Keep POMs Readable and Maintainable
+### Example 5: Keep POMs Readable and Maintainable
 
 Title: Structure POMs Logically for Readability
 Description: Organize your `pom.xml` sections in a consistent order (e.g., project coordinates, parent, properties, dependencyManagement, dependencies, build, profiles, repositories). Use properties for recurring versions or values. Add comments for complex configurations.
@@ -344,9 +354,10 @@ Description: Organize your `pom.xml` sections in a consistent order (e.g., proje
     <!-- Repositories and Plugin Repositories (if needed) -->
     <!-- ... -->
 </project>
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
 ```xml
 <!-- Haphazard order, missing properties for versions -->
@@ -369,9 +380,10 @@ Description: Organize your `pom.xml` sections in a consistent order (e.g., proje
   <artifactId>my-app</artifactId>
   <version>1.0.0-SNAPSHOT</version>
 </project>
+
 ```
 
-## Rule 6: Manage Repositories Explicitly
+### Example 6: Manage Repositories Explicitly
 
 Title: Declare Custom Repositories Explicitly and Minimize Their Use
 Description: Prefer dependencies from Maven Central. If custom repositories are necessary, declare them in the `<repositories>` section and `<pluginRepositories>` for plugins. It's often better to manage these in a company-wide Nexus/Artifactory instance configured in `settings.xml` rather than per-project POMs. Avoid relying on transitive repositories.
@@ -395,9 +407,10 @@ Description: Prefer dependencies from Maven Central. If custom repositories are
   </pluginRepositories>
 </project>
 <!-- Better: Configure these in settings.xml and use a repository manager -->
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
 ```xml
 <!-- No explicit repository for a non-central artifact, relying on developer's local settings or transitive ones -->
@@ -414,9 +427,10 @@ Description: Prefer dependencies from Maven Central. If custom repositories are
     </dependency>
   </dependencies>
 </project>
+
 ```
 
-## Rule 7: Centralize Version Management with Properties
+### Example 7: Centralize Version Management with Properties
 
 Title: Use Properties to Manage Dependency and Plugin Versions
 Description: Define all dependency and plugin versions in the `<properties>` section rather than hardcoding them throughout the POM. This centralizes version management, makes updates easier, reduces duplication, and helps maintain consistency across related dependencies. Use consistent property naming conventions: `maven-plugin-[name].version` for Maven plugins, simple names like `[library].version` for dependencies, and descriptive names for quality thresholds like `coverage.level`.
@@ -436,22 +450,22 @@ Description: Define all dependency and plugin versions in the `<properties>` sec
     <maven.version>3.9.10</maven.version>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
-    
+
     <!-- Dependency versions -->
     <jackson.version>2.15.3</jackson.version>
     <junit.version>5.10.1</junit.version>
     <mockito.version>5.7.0</mockito.version>
     <logback.version>1.4.11</logback.version>
-    
+
     <!-- Maven plugin versions -->
     <maven-plugin-compiler.version>3.14.0</maven-plugin-compiler.version>
     <maven-plugin-surefire.version>3.5.3</maven-plugin-surefire.version>
     <maven-plugin-failsafe.version>3.5.3</maven-plugin-failsafe.version>
     <maven-plugin-enforcer.version>3.5.0</maven-plugin-enforcer.version>
-    
+
     <!-- Third-party plugin versions -->
     <maven-plugin-jacoco.version>0.8.13</maven-plugin-jacoco.version>
-    
+
     <!-- Quality thresholds -->
     <coverage.level>80</coverage.level>
     <mutation.level>70</mutation.level>
@@ -501,9 +515,10 @@ Description: Define all dependency and plugin versions in the `<properties>` sec
     </plugins>
   </build>
 </project>
+
 ```
 
-**Bad Example:**
+**Bad example:**
 
 ```xml
 <!-- Hardcoded versions scattered throughout the POM -->
@@ -567,4 +582,9 @@ Description: Define all dependency and plugin versions in the `<properties>` sec
     </plugins>
   </build>
 </project>
+
 ```
+## Output Requirements
+
+- Update the file pom.xml if something is not correct
+- verify changes with the command: `mvn validate`

.cursor/rules/112-java-maven-documentation.mdc

@@ -5,52 +5,27 @@ alwaysApply: false
 ---
 # Create README-DEV.md with information about how to use the Maven project
 
-## System prompt characterization
+## Role
 
-Role definition: You are a Senior software engineer with extensive experience in Java software development
+You are a Senior software engineer with extensive experience in Java software development
 
-## Description
+## Instructions for AI
 
 When creating a README-DEV.md file for a Maven project, include ONLY the following sections with the specified Maven goals. Do NOT add any additional sections, explanations, or content beyond what is explicitly listed below.
 
-## STRICT Structure for README-DEV.md (Template):
+Create a markdown file named `README-DEV.md` with the following exact structure: [java-maven-documentation-template.md](mdc:.cursor/rules/templates/java-maven-documentation-template.md)
 
-**IMPORTANT: Include ONLY the content specified below.**
+## Restrictions
 
----
-
-# Essential Maven Goals:
-
-```bash
-# Analyze dependencies
-./mvnw dependency:tree
-./mvnw dependency:analyze
-./mvnw dependency:resolve
-
-./mvnw clean validate -U
-./mvnw buildplan:list-plugin
-./mvnw buildplan:list-phase
-./mvnw help:all-profiles
-./mvnw help:active-profiles
-./mvnw license:third-party-report
-
-# Clean the project
-./mvnw clean
-
-# Clean and package in one command
-./mvnw clean package
-
-# Run integration tests
-./mvnw verify
+**MANDATORY REQUIREMENT**: Follow the embedded template EXACTLY - do not add, remove, or modify any steps, sections, or cursor rules that are not explicitly shown in the template. ### What NOT to Include:
 
-# Check for dependency updates
-./mvnw versions:display-property-updates
-./mvnw versions:display-dependency-updates
-./mvnw versions:display-plugin-updates
+- **DO NOT** create additional steps beyond what's shown in the template
+- **DO NOT** expand or elaborate on sections beyond what the template shows
+- **ONLY** use the exact wording and structure from the template
+- If a cursor rule exists in the workspace but is not in the template, **DO NOT** include it
 
-# Generate project reports
-./mvnw site
-jwebserver -p 8005 -d "$(pwd)/target/site/"
-```
+## Output Requirements
 
-**END OF TEMPLATE - DO NOT ADD ANYTHING BEYOND THIS POINT** 
+- Generate the complete markdown file following the embedded template exactly
+- Use proper markdown formatting with headers, code blocks, tables, and checklists
+- **VERIFY**: Final output contains ONLY what appears in the embedded template