[efegokdemir]

Summary

Preserve closing braces inside {@code ...} content when legacy Javadoc tags are converted to XHTML. This prevents expressions such as ${project.basedir} from prematurely terminating the inline tag.

Changes

• Allow balanced braces in the Javadoc inline-tag matcher.
• Add a regression test covering nested braces in a multiline code block.

Testing

• mvn -pl maven-plugin-tools-generators -am -Dspotless.apply.skip=true -Dspotless.check.skip=true -Dcheckstyle.skip=true -Drat.skip=true test — passed (61 API tests; 18 generator tests, 1 skipped)
• git diff --check — passed

spotless:check was attempted but is blocked by the local JDK/Palantir formatter incompatibility (NoSuchFieldError in JCTree$JCCompilationUnit).

Fixes #823

[gnodet-bot]

LGTM. Correct fix for the brace-nesting bug in decodeJavadocTags().

Pre-fix test validation: ✅ 2 of 4 new tests (decodeJavadocCodeWithNestedClosingBrace, decodeJavadocCodeWithMultipleLevelsOfNestedBraces) fail against the base code and pass with the fix. All 21 module tests pass.

Analysis:

• findInlineTagEnd() brace-counting correctly matches javac's doclet behavior. Backslashes are literal in Javadoc (not escape characters) — \{ increments depth and \} decrements it, so the test for \{braces\} content is correct.
• quoteReplacement() removal is safe: the old helper was only needed to suppress $/\ special-meaning in appendReplacement(), which is no longer called. Direct decoded.append(text) has no such interpretation.
• Skip-on-unmatched-brace logic (searchFrom = matcher.start() + 2) is correct — advances past {@ without risking re-match of the same position.
• StringBuffer → StringBuilder: decodeJavadocTags() is not shared across threads; the change is safe.

Note: The same bug exists in the maven-plugin-tools-3.x branch (same quoteReplacement/appendReplacement pattern). Consider opening a backport PR for milestone 3.16.1.

This review was generated by an AI agent, Hermès on behalf of @gnodet.