On Fri, May 16, 2025 at 1:43 AM Vincent Potucek <vpotu...@me.com.invalid> wrote:
> Dear colleagues, > I am not your colleague. Frankly, posting with a mail address of "me.com.invalid" makes me press "Spam" usually right away. As this message has received some replies from other developers, here is my take: "Vendor spam". This is a pretty questionable way to engage with this group. Based on last year's license change for part of the code base (see https://medium.com/@jonathan.leitschuh/when-open-source-isnt-how-openrewrite-lost-its-way-642053be287d) I am not sure that such an engagement is in good faith. I would stay away from that tool. -h > It’s great to see our codebase seriously embracing functional programming, > leveraging higher-order functions and avoiding boilerplate. This is a > fantastic achievement and a testament to the progress discussed in recent > PRs. > > I'd like to propose enhancing our code quality tooling by introducing > OpenRewrite, which would complement our existing Spotless and Checkstyle > setup. > > Current Situation: > > Spotless handles formatting (cosmetic changes) > > Checkstyle performs basic static analysis (file-level parsing) > > Both have limited capabilities in detecting and automatically fixing > deeper code quality issues > > The Problem: > > We’re missing type-aware static analysis that can: > > Detect more sophisticated issues in the codebase > > Automatically fix them (reducing manual effort) > > Catch patterns typically handled by PMD or SpotBugs > > Why OpenRewrite? > > Goes beyond formatting to fix real code issues > > Can automatically remediate many common problems > > Integrates well with existing tools > > Offers recipes for security best practices, removing unused code, and more > > Example Benefits: > > Fix wildcard imports (not currently handled by Spotless) > → GitHub Issue #5413 < > https://github.com/openrewrite/rewrite/issues/5413#issuecomment-2885362961 > > > Remove unused parameters, variables, and methods > > Apply secure coding practices (e.g., secure temp file creation) > > Automate JUnit migrations > > Covers 400+ bug patterns with ready-to-use and extensible recipes > > Notable Recipes: > > RemoveUnusedParams > → PR #560 <https://github.com/openrewrite/rewrite-static-analysis/pull/560 > > > → Maven PR #2338 <https://github.com/apache/maven/pull/2338> > ReplaceCollectToListWithToList > → PR #558 <https://github.com/openrewrite/rewrite-static-analysis/pull/558 > > > → Maven PR #2277 <https://github.com/apache/maven/pull/2277> > Implementation Approach: > > Add as an optional profile, similar to Spotless > > Supports dry-run mode to preview changes before applying > > Can be automated to run in full auto-fix mode, like Spotless > > Optionally fail builds on detected issues, like Checkstyle > > This wouldn’t replace our current tools but would add another layer of > quality control, while reducing maintenance overhead through automated > fixes. > > Before moving forward, I’d love to hear your thoughts: > > Does this direction make sense? > > Any concerns about adding another tool? > > Any specific recipes you’d like to include or exclude? > > I believe this could greatly enhance our code quality and maintainability > with minimal overhead. The extra CPU cycles are likely worth the long-term > savings in manual review and rework. > > POC: Apache Maven PR #2322 <https://github.com/apache/maven/pull/2322> > Looking forward to your feedback. > > Best regards, > Vincent > > >
