@romani

So I did fix for switch expression lambda indentation. I made changes, they're working correctly. But because they're working correctly, now it's catching previously missed violations in external projects like Kafka and PMD that test against checkstyle. The CI jobs are failing since they're catching these errors. Here are examples of where the errors are being thrown on legitimate places:

no-error-xwiki:
[ERROR] src/main/java/org/xwiki/rendering/internal/macro/toc/TocTreeBuilder.java:[260,21] (indentation) Indentation: 'lambda arguments' has incorrect indentation level 20, expected level should be 12.

The actual file itself:
https://github.com/xwiki/xwiki-rendering/blob/340dc7df070ae12a660a8f3fcffb6218257f2de1/xwiki-rendering-macros/xwiki-rendering-macro-toc/src/main/java/org/xwiki/rendering/internal/macro/toc/TocTreeBuilder.java#L257-L263

no-error-pmd:

[ERROR] src/main/java/net/sourceforge/pmd/lang/java/ast/internal/JavaAstUtils.java:[306,37] (indentation) Indentation: 'lambda arguments' has incorrect indentation level 36, expected level should be one of the following: 20, 32. [ERROR] src/main/java/net/sourceforge/pmd/lang/java/symbols/internal/ImplicitMemberSymbols.java:[164,25] (indentation) Indentation: 'lambda arguments' has incorrect indentation level 24, expected level should be one of the following: 16, 20.

The actual files:
https://github.com/pmd/pmd/blob/237f5cfabccb4e46db57b7095d2b07eb99fe93bd/pmd-java/src/main/java/net/sourceforge/pmd/lang/java/ast/internal/JavaAstUtils.java#L303-L308

https://github.com/pmd/pmd/blob/237f5cfabccb4e46db57b7095d2b07eb99fe93bd/pmd-java/src/main/java/net/sourceforge/pmd/lang/java/symbols/internal/ImplicitMemberSymbols.java#L159-L166

Kafka has similar violations.
My real question is what should be done in this situation? Should we suppress the violations for external projects?

@vivek-0509 you're an expert with indentation mutation logic, do these look right to you? Since you have the context fresh in your mind, do you think these errors in PMD look like valid violations to you, or is it accidentally too strict?

My real question is what should be done in this situation? Should we suppress the violations for external projects?

we should send them fixes by PRs, ideally they can merge it before we finish this PR. If behavior is not compatible, we still create PR, and we can update CI jobs to use your PRs branch to let CI pass on your fixes, and such projects will merge PRs after we release your fix.

Github, generate report for Indentation/all-examples-in-one

Failed to parse comment command.

Please ensure you've used one of the valid command formats.

Link: https://github.com/checkstyle/checkstyle/actions/runs/21520419374

Report for Indentation/all-examples-in-one:
https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/824e186a94604a0f5a43b83359e94e2631409086_2026205550/reports/diff/index.html

Report for Indentation/all-examples-in-one: https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/824e186a94604a0f5a43b83359e94e2631409086_2026205550/reports/diff/index.html

The violations are valid. It's interesting, even such a minimal change in MethodCallHandler.java‎ can affect so many return statements. Though it's mostly when <property name="forceStrictCondition" value="true"/>

I'll start sending PRs to the other repos