[S1161] Add missing @Override to overriding and implementing methods

[Pankraz76]

• https://sonarsource.github.io/rspec/#/rspec/S1161

[Pankraz76]

@slachiewicz is this too much big-bang?

could simply split this into each module, therefore avoid potential merge / backwards compatibility issues.

[Pankraz76]

thx.

[Pankraz76]

need to ship this prior to #2415 as might interfere.

• Fix 'string builder buffer' can be replaced with 'string'  #2415

[Pankraz76]

@gnodet ready for merge or should supplement each module?

[Pankraz76]

Hello devs,

Given the current state of the Maven codebase—where even basic conventions like proper @OverRide annotations are not consistently followed, and there's misalignment with JCC—it’s clear that things are out of control. There is a vacuum in chaos waiting to be filled with natural order and structure.

Bringing in discipline through static code analysis tools is a straightforward and necessary step. At scale, humans inevitably introduce errors—it’s in our nature. We’re not always great at spotting or fixing them without help. That’s why automated tools are essential.

This isn’t about opinion or individuals. It’s about acknowledging the system and its flaws—and improving it. The current setup is leaking quality, and it's risky to ignore that.

Introducing tools like PMD and aligning with Sonar rules can help us catch and prevent issues early. Here are some relevant references:

• https://sonarsource.github.io/rspec/#/rspec/S1161
• [S1161] Enable PMD check MissingOverride #2403

Let’s take this opportunity to level up our standards and tooling.

My suggestion would be to align on some basic standards and start simple with a PoC for S1161, as this should be a common norm to align everybody—even those who have trouble letting things go.

Best regards,
Vinc

[elharo]

It sounds like you might not be accustomed to legacy projects with decades long history that predate conventions like @OverRide. Not every project is a greenfield, and other factors come into play, including source code history and compatibility with a large installed base. It's also important to recognize that Maven has been analyzed with various tools over the years and a lot (not all but a lot) of the low hanging fruit has been picked. "Violations" that remain are as often as not deliberate and well considered. Most static code analyzers are overly confident and riddled with false positives. For instance, the plexus dependency injection used throughout maven triggers many warnings about "unset" fields tjat are set and are asbolutely critical to Maven's functioning. Human attention is necessary.

[gnodet]

Could we setup the tools in PRs only so that it would comment and provide fixes as suggestions ? We would keep it on CI only ?

[Pankraz76]

provide fixes

yes, that would be awesome and possible with open rewrite.

• https://docs.openrewrite.org/recipes/staticanalysis/missingoverrideannotation
• [POC] rewrite-maven-plugin: Introduce OpenRewrite by Moderne #2322

[Pankraz76]

whats the issue with licence? do they send out bill, or try to claim maven then?

do not expect anything from mentioned scenarios, so whats the deal breaker?

as long we dont contribute, i see no problem with this. If its "free/possible" to use, why not.

i have no experience with this, but seeing all the comments it seems a valid concern.

[gnodet]

Please remove the unrelated links in the PR description.

[Pankraz76]

mon coeur.

[Pankraz76]

lets undo, as nobody cares.

It seems @slachiewicz wants to promote silly boilerplate.