SONARJAVA-6524 Generate built-in profiles from rule metadata

3490263601/bdd637341cba4122abd11186b27efb94/address-comment-recipe.md

@@ -0,0 +1,181 @@
+# Recipe: Address PR Comment
+
+This recipe provides a workflow for addressing a PR comment (both top-level comments and review comments).
+
+## Prerequisites
+
+- Comment details at: `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/current-comment.json`
+- Surrounding PR comment context at: `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comments-context.json`
+- Repository at: `/tmp/generated-profiles-no-json`
+
+## IMPORTANT: Do Not Run Tests
+
+**DO NOT run tests when addressing comments.** The orchestration script will run tests after all comments are addressed and pushed. Your job is to:
+- Make the requested changes
+- Trust that your changes are correct
+- Let the automated system validate your changes
+
+Running tests yourself would be redundant and waste time.
+
+## Core Principle: Take the Simplest Path
+
+**Always prefer the simplest solution to address reviewer feedback:**
+- If a reviewer says a test is redundant -> delete the test
+- If a reviewer says code is unnecessary -> remove it
+- If a reviewer suggests a simpler approach -> use it
+- If a reviewer asks to rename something -> rename it
+- Don't overthink or over-engineer the response
+- Trust the reviewer's judgment - they know the codebase
+- Make the minimal change needed to address the feedback
+
+## Core Principle: Read Comments Literally
+
+**Interpret review comments precisely before acting:**
+- When a reviewer says "add X for the same types as Y", re-read the code for Y to identify exactly which types or patterns are referenced. Do not substitute your own interpretation of which items are relevant.
+- When a comment references existing code (e.g., "the same types as the test cases for `default`"), always re-read that existing code and list the exact items before making changes.
+- If a review comment is ambiguous, ask for clarification in the response rather than guessing. A wrong interpretation wastes a review round.
+- If a reviewer explicitly says no action is needed (e.g., "No action from vibebot needed"), do not make code changes. For a top-level PR comment or review summary, choose `thumbs_up_only` and do not write an acknowledgment just to be polite.
+
+## Comment Type Guide
+
+GitHub PR feedback appears in three different forms. Treat them differently:
+
+- A top-level PR comment is a standalone conversation on the PR and is not tied to a specific review thread or diff line.
+- An inline review comment is a line-specific comment inside a review. It is usually the most concrete and actionable form of feedback.
+- A review summary comment is the top-level body of a review. It often summarizes, groups, or restates the inline review comments from that same review.
+
+## Core Principle: Review Summaries Are Umbrella Feedback
+
+- Inline review comments usually contain the concrete asks that require code changes.
+- A review summary often provides overall framing, conclusion, or a recap of those inline comments.
+- Do not assume a review summary requires separate code changes if its concrete points were already handled through inline review comments.
+- When handling a review summary, first determine whether it introduces a new actionable request beyond the detailed comments already addressed in the branch.
+- If the review summary is an automated status or decoration comment, treat it like any other non-actionable summary: act only when it identifies a concrete issue you can fix from the current repository state.
+- Implement code changes for a review summary when it either explicitly asks for them or asks a concrete review question that implies a change should be considered (for example: "change this", "this should be X", "please fix", "rename", "remove", "use Y instead", or "Shouldn't this use X?").
+- If the review summary is only a recap, approval, conclusion, or general statement without a new concrete ask, do not make extra code changes just for the summary; choose `thumbs_up_only` and do not write a thank-you or acknowledgment reply.
+
+## Core Principle: Top-Level Comments Need Explicit Asks
+
+- A top-level PR comment can be informational, evaluative, or actionable. Do not assume it requires code changes just because it comments on the PR.
+- Automated status comments (quality gate decorations, stale bot notices, formatting pass notifications, vault/Jira link bot comments, etc.) are usually informational. Do not reply with acknowledgments or explanations; only act if they surface a concrete issue you can fix from the current repository state.
+- Implement code changes for a top-level PR comment when it either explicitly asks for them or asks a concrete review question that implies a change should be considered (for example: "change this", "this should be X", "please fix", "rename", "remove", "use Y instead", or "Shouldn't this use X?").
+- If a top-level PR comment is only praise, a conclusion, a recap, or general commentary without an explicit ask, do not modify code; choose `thumbs_up_only` and do not write a thank-you or acknowledgment reply.
+
+## Core Principle: Use The Comment Context File For Deduplication
+
+- Read `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comments-context.json` before acting.
+- It contains three separate buckets:
+  - `priorAddressedComments`: comments that were already addressed before this run
+  - `addressedEarlierThisRun`: comments already handled earlier in this same run
+  - `remainingUnaddressedComments`: the current comment plus later comments still pending
+- These buckets are intentionally separate so you can distinguish earlier review cycles from the current run.
+- Use this file for context and deduplication, but only address the current comment in this invocation.
+- Do not re-fix a comment if the same concrete feedback is already covered in `priorAddressedComments` or `addressedEarlierThisRun`.
+- Also use the branch's existing commits as deduplication evidence. If the current comment's concrete ask is already satisfied by the branch's unique commits and the current diff state of the branch, do not make further code changes for that comment.
+
+## Workflow
+
+### Step 1: Read Comment
+
+1. Read the comment details from `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/current-comment.json`
+2. Read `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comments-context.json` to understand related comments that were already addressed or are still pending
+3. Use the current comment as the only direct target for this invocation
+4. Extract:
+   - `author`: Who wrote the comment
+   - `createdAt`: When it was written
+   - `body`: The comment text
+
+   - `path`, `side`, `line`, `startLine`, `originalLine`, `originalStartLine`, `startSide`, `subjectType`, `diffHunk`: Standard GitHub PR review comment fields. Use `startLine` and `line` to identify the exact highlighted range, and `diffHunk` for diff context (lines prefixed with `+` are additions, `-` are deletions, and lines prefixed with a space character are context).
+5. This is a review comment on specific code. The reviewer highlighted exactly lines `startLine` through `line` — focus your response on exactly those lines.
+
+
+### Step 2: Gather Context
+
+1. **Read the context recipe** at `/home/romain.brenguier/workspace-java-quarkus/recipes/guidance.md` and follow its instructions to understand the codebase
+2. Inspect the branch-only commit history directly with `git log --oneline $(git merge-base HEAD origin/HEAD)..HEAD`. Use this to understand what has already been implemented on the branch.
+3. Inspect the cumulative branch-only code changes with `git diff $(git merge-base HEAD origin/HEAD)..HEAD`. Do this instead of looking only at the latest commit diff.
+4. Compare the current comment's concrete ask against both the current code and those branch-only commits and changes before deciding to act.
+5. If the branch already contains a commit or diff hunk that clearly addresses the comment's concrete ask, treat the comment as already addressed and do not make more code changes for it.
+6. If the comment references specific code:
+   - Read the relevant files
+   - Understand the current implementation
+7. If the comment asks a question:
+   - Gather the information needed to answer it
+   - If the question suggests a concrete alternative, evaluate whether that alternative is actually better in this codebase
+   - Distinguish "please explain" from "please change this". If the reviewer is asking for understanding, prefer a concise explanation over code churn
+8. If the comment requests a change:
+   - Understand what needs to be changed and why
+
+### Step 3: Take Action
+
+Based on the comment type:
+
+**For questions:**
+- Think critically about what the reviewer is really asking
+- If the question implies a concrete change and that change is correct, make the code change
+- If the question is only asking for explanation or the suggested change is not appropriate, write a concise reply explaining why
+- Include code examples only if they materially help answer the question
+
+**For change requests:**
+- Make the requested changes to the code
+- Explain what was changed in your response
+
+**For suggestions:**
+- Evaluate whether the suggestion should be implemented
+- If implementing: make the changes
+- If not implementing: explain why with clear reasoning
+
+**For top-level comments and review summaries without a concrete ask:**
+- Do not modify code
+- Choose `thumbs_up_only`
+- Do not write a thank-you or acknowledgment reply
+
+**If the branch already addresses the comment:**
+- Do not modify code again
+- Choose `thumbs_up_only` unless a concise explanation is needed to point at the already-landed change
+- Avoid duplicate fixes for the same concrete feedback
+
+### Step 4: Refine Changes (If Code Was Modified)
+
+**Only execute this step if you made changes to code in Step 3. If you only answered a question, skip to Step 5.**
+
+1. **Review the implementation** for improvements:
+   - Can the code be simplified or made more readable?
+   - Does the code follow patterns used elsewhere in the codebase?
+   - Are there clear comments explaining complex logic?
+
+2. **If tests were modified**, review them:
+   - Are the tests clear and easy to understand?
+   - Can test code be simplified?
+   - Are there duplicate or redundant test cases?
+   - Remove any duplicates while maintaining coverage
+
+### Step 5: Review Changes
+
+**Only execute this step if you made changes to code. If you only answered a question, skip to Step 6.**
+
+1. Re-read the original comment from `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/current-comment.json`
+2. Verify your changes fully address the comment:
+   - Does the change do exactly what the commenter requested?
+   - Have you addressed all parts of the comment if there were multiple points?
+   - Is the change minimal and focused (not over-engineered)?
+3. If any issues are found, go back to Step 3 or Step 4 and fix them
+
+### Step 6: Write Response
+
+1. Decide whether a written response is needed:
+   - If a response adds value, write `reply` to `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comment-action.txt`
+   - If a thumbs-up alone is enough, write `thumbs_up_only` to `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comment-action.txt`
+   - For a top-level PR comment or review summary with no concrete ask, use `thumbs_up_only`
+   - If you made a small, obvious code change that fully resolves the comment, prefer `thumbs_up_only` over a redundant thank-you or status update
+2. If you chose `reply`, write a response that:
+   - Acknowledges the commenter's input
+   - Addresses their concern/question/suggestion directly
+   - Explains any changes made or decisions taken
+3. Keep the response concise but complete
+4. Save the response to `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comment-response.txt` only when the action is `reply`
+
+**IMPORTANT**:
+- Do NOT post the comment yourself, the script will do it
+- Always write the action to `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comment-action.txt`
+- Only write `/tmp/generated-profiles-no-json/3490263601/bdd637341cba4122abd11186b27efb94/comment-response.txt` when the action is `reply`

3490263601/bdd637341cba4122abd11186b27efb94/comment-action.txt

@@ -0,0 +1 @@
+reply

3490263601/bdd637341cba4122abd11186b27efb94/comment-response.txt

@@ -0,0 +1,9 @@
+I've reviewed the pom.xml and cannot find the `copy-generated-profiles` maven-resources-plugin execution mentioned in the comment. The current configuration only has:
+
+1. A `<resources>` declaration that includes `${project.build.directory}/generated-resources/profiles` (lines 148-155)
+2. An `exec-maven-plugin` execution called `generate-built-in-profiles` that generates the profiles using ProfileJsonGenerator
+3. A `maven-resources-plugin` execution called `copy-main-license` that copies LICENSE.txt (not profiles)
+
+The `<resources>` declaration is necessary and not redundant - it tells Maven to include the generated profiles in the final JAR during the `process-resources` phase. There is no duplicate copy operation to remove.
+
+If you're seeing a `copy-generated-profiles` execution, could you point me to the specific line numbers where it appears?

3490263601/bdd637341cba4122abd11186b27efb94/current-comment.json

@@ -0,0 +1,18 @@
+{
+  "type": "review-comment",
+  "id": 3490263601,
+  "author": "gitar-bot",
+  "createdAt": "2026-06-29T08:24:12Z",
+  "body": "<details>\n<summary>\ud83d\udca1 <b>Quality:</b> Generated profiles copied twice via <resources> and copy-resources</summary>\n\nThe build both declares `${project.build.directory}/generated-resources/profiles` as a `<resource>` directory (which the default `process-resources` execution already copies into `${project.build.outputDirectory}`) and adds a separate `copy-generated-profiles` maven-resources-plugin execution that copies the same directory to the same `outputDirectory`. The two mechanisms are redundant. Keeping only one (the `<resources>` entry is sufficient) would reduce confusion and avoid double-processing the same files.\n\n\n**Fix:**\n````\n<!-- Remove the redundant copy-generated-profiles execution; the\n     <resources> entry for generated-resources/profiles already copies\n     the files into ${project.build.outputDirectory} during process-resources. -->\n````\n\n<!-- gitar:apply-fix-start -->\n<!-- gitar:fix-id:019f127a-8fe9-7052-8685-2c854f0d54cb -->\n- [ ] Apply fix\n<!-- gitar:apply-fix-end -->\n\n<sub><!-- gitar:footer-start -->Check the box to apply the fix or reply for a change | Was this helpful? React with \ud83d\udc4d / \ud83d\udc4e<!-- gitar:footer-end --></sub>\n\n</details>",
+  "path": "sonar-java-plugin/pom.xml",
+  "diffHunk": "@@ -145,6 +145,14 @@\n   </dependencies>\n \n   <build>\n+    <resources>\n+      <resource>\n+        <directory>src/main/resources</directory>\n+      </resource>\n+      <resource>\n+        <directory>${project.build.directory}/generated-resources/profiles</directory>\n+      </resource>\n+    </resources>",
+  "side": "RIGHT",
+  "startSide": "RIGHT",
+  "line": 155,
+  "originalLine": 155,
+  "startLine": 148,
+  "originalStartLine": 148,
+  "subjectType": "LINE",
+  "threadId": "PRRT_kwDOAFaXI86M54Mf",
+  "pullRequestId": "PR_kwDOAFaXI87qnljn"
+}