SONARJAVA-6524 Generate built-in profiles from rule metadata

[romainbrenguier]

Summary

• generate the Sonar way and Sonar agentic AI profile JSON files during the build
• move built-in profile membership into the per-rule metadata files and stop tracking the generated profile JSONs
• update plugin tests to validate the generated classpath resources instead of src/main/resources files

Testing

• mvn -pl sonar-java-plugin -am -DskipLicenseValidation -Dsurefire.failIfNoSpecifiedTests=false -Dtest=MetadataTest,JavaAgenticWayProfileTest,JavaSonarWayProfileTest test

---

Summary by Gitar

• Build Infrastructure:
  • Introduced ProfileJsonGenerator.java to automate the creation of profile JSON files during the build process.
  • Updated pom.xml to include generated resource directories and configured exec-maven-plugin to execute the generator.
• Documentation:
  • Added README.md in src/main/resources/profiles/ detailing the new rule management and build process.
• Test Updates:
  • Updated JavaAgenticWayProfileTest to reflect the change in the total count of active rules from 465 to 467.

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-6524

[romainbrenguier]

Thanks for the comprehensive review. I've addressed both remaining suggestions:

1. Removed redundant copy-generated-profiles execution (sonar-java-plugin/pom.xml:397-411) - The <resources> entry already handles copying the generated profiles during process-resources, so the separate copy-resources execution was indeed redundant.

2. Added warning for misnamed rule-key files (sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:67-73) - Added .peek() to log a warning to stderr when non-rule-key files are encountered in profile directories, making it easier to catch typos or stray files at build time.

Both changes improve the build configuration clarity and help prevent silent profile-membership mistakes.

[gitar-bot]

Code Review ✅ Approved 7 resolved / 7 findings

Automates profile JSON generation from rule metadata during the build and transitions to directory-based profile composition. All previous findings regarding parsing fragility, stale resource handling, and silent failures have been resolved.

✅ 7 resolved

✅ Quality: Profile generator silently drops rules with unknown profile names

📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:64-72 📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:84-97
collectKeysByProfile looks up each profile name extracted from a rule's defaultQualityProfiles with keysByProfile.get(profile) and only adds the rule key when the returned list is non-null. Any profile name that is not exactly one of the two keys in PROFILES ("Sonar way", "Sonar agentic AI") is therefore silently ignored.

This migration moves profile membership into ~500 hand-edited rule metadata files, so a typo such as "Sonar Way", "sonar way", or "Sonar agentic Al" in any single rule would silently exclude that rule from the built-in profile with no error. The safety nets are weak: MetadataTest.ensure_sane_Sonar_way_profile only asserts the Sonar way size is > 400, so a handful of dropped rules would go completely unnoticed (the agentic test uses an exact size, but Sonar way does not). Likewise, a rule whose JSON omits defaultQualityProfiles entirely is silently excluded.

Recommend failing the build (or at minimum warning) when a rule references a profile name that is not in PROFILES, so accidental omissions surface at build time instead of shipping an incomplete profile.

✅ Quality: Regex-based JSON parsing in ProfileJsonGenerator is fragile

📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:33-35 📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:84-97 📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:99-105
ProfileJsonGenerator extracts sqKey and defaultQualityProfiles via hand-written regular expressions rather than a JSON parser. This works for the current well-formatted metadata, but it is brittle: JSON_STRING_PATTERN blindly captures every quoted token inside the defaultQualityProfiles array, so any future change such as an inline comment, an escaped quote, or reformatting could yield wrong profile names or miss entries. Because the generator runs as a single-file source launch (java ProfileJsonGenerator.java) it cannot easily depend on Gson; however the fragility is worth a comment and tight patterns. Consider at least documenting the assumption that metadata files are machine-generated and strictly formatted, and validating extracted profile names against the known set (see related finding) so malformed input cannot silently produce an incorrect profile.

✅ Bug: Stale source profile JSONs collide with generated ones

📄 sonar-java-plugin/pom.xml:148-155 📄 sonar-java-plugin/pom.xml:397-411 📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:42 📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:56-57
The PR's stated goal is to "stop tracking the generated profile JSONs," but the old hand-maintained files are still present in source: sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json and Sonar_agentic_AI_profile.json (the diff shows 0 deletions). ProfileJsonGenerator now writes freshly generated files to the SAME packaged path (org/sonar/l10n/java/rules/java/Sonar_way_profile.json).

In the pom, both src/main/resources and ${project.build.directory}/generated-resources/profiles are declared as resource directories (lines 148-155), and there is also a copy-generated-profiles copy-resources execution. Both the stale src copy and the generated copy resolve to the identical target path in target/classes. Which one ends up packaged depends entirely on maven-resources-plugin copy ordering and its overwrite timestamp semantics (by default a resource is only copied when the source is newer than the destination). This is fragile: the plugin may ship the stale, hand-maintained profile instead of the generated one, and at minimum the two definitions can silently diverge while both remain authoritative-looking.

Delete the old Sonar_way_profile.json / Sonar_agentic_AI_profile.json from src/main/resources so the generated artifact is the single source of truth, and ensure the per-rule profile membership files fully reproduce the previous profile contents.

✅ Edge Case: numericKey throws cryptic NumberFormatException on stray files

📄 sonar-java-plugin/src/main/build/ProfileJsonGenerator.java:61-75
collectRuleKeys lists every regular file in a profile directory and feeds each filename to numericKey, which does Integer.parseInt(ruleKey.substring(1)). Any file whose name is not exactly S<digits> — e.g. a .gitkeep, .DS_Store, editor swap file, or a typo'd rule key such as S891O (letter O) — causes a NumberFormatException that aborts the build with an opaque message ("For input string ...") and no indication of the offending directory/file.

Consider filtering to files matching S\d+ (and/or sorting with a fallback comparator) and throwing a descriptive error that names the bad file, so contributors immediately understand the problem.

✅ Bug: MetadataTest reads deleted src/main/resources profile JSON

📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/.gitignore:1
This PR deletes src/main/resources/org/sonar/l10n/java/rules/java/Sonar_way_profile.json (and the agentic one) and adds a .gitignore for *_profile.json, so the profile JSONs now only exist as generated artifacts under target/generated-resources / target/classes. However MetadataTest.ensure_sane_Sonar_way_profile() still reads the profile via a hard-coded filesystem path: Path.of("src/main/resources/" + JavaSonarWayProfile.SONAR_WAY_PATH) and opens it with Files.newReader(profilePath.toFile(), ...). Since that file no longer exists in the source tree, the test will fail with FileNotFoundException. This test is explicitly listed in the PR's test command (-Dtest=MetadataTest,...). The PR description says tests should be updated 'to validate the generated classpath resources instead of src/main/resources files', but MetadataTest was not updated. Point the test at the generated output (e.g. target/classes + SONAR_WAY_PATH) or load it from the classpath via getResourceAsStream(SONAR_WAY_PATH).

...and 2 more resolved from earlier reviews

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube