Replies: 22 comments 57 replies
-
|
example: #5635 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the suggestion. I think, it makes sense to add this config. But we need to mention it in the documentation, as not all IDEs/Editors use it by default. Some (like VS Code) need a plugin. So the relevant documentation needs to be updated:
Also, if we have this config, then I assume, we don't need e.g. the IntelliJ Specific config anymore? |
Beta Was this translation helpful? Give feedback.
-
Yes I think so too, but @romani has different opinion. We will find out after migration, if we still need the file for manual config. @Anmol202005 ATM its The setting-up-checkstyle file is needed, as it will evolve into the new |
Beta Was this translation helpful? Give feedback.
-
|
What about Spotless? How is it related (or not) to editorconfig? Can you please explain how all of those fit together and how you think we should proceed with migration to a new set of code quality plugins? Can we remove checkstyle? Are there any things that we use in checkstyle and that are not supported by spotless? How do we keep the spotless formatter synced with IDE configs? And how is a developer supposed to use these plugins? I wouldn't want the default behavior of I think we should answer those questions and finish this discussion before we merge or even review your PRs @Pankraz76. Your PRs #5846 #5845 #5636 and #5776 are huge and overlap, which make them difficult to review. The main problem is however that you haven't explained anywhere, in detail, what you're trying to do or how you want to get there. You should do that before you open PRs, especially if they are numerous and large. Please take your time to write your case here; in the meantime I will close your PRs. |
Beta Was this translation helpful? Give feedback.
-
|
ah nice, thanks yes. The topic does not change. Only the somehow, as constantly evolving, irrelevant impl. details. I have overcome myself, thanks to the learnings of maven and quarkus. As we already agreed upon, fixing things once and for everybody, we dont need this plugin anymore as spotless is the successor, automating this burden.
Long story short, in order not to reinvent the wheel, we should leverage the convention over configuration principle and follow big bother maven, at least for You need to check if its worth to fix the eclipse config or be smart like maven let palantir to the job. https://github.com/apache/maven-parent/blob/f4ab7c2eb04865071186c57a263243c72b6e8d52/pom.xml#L1219 Starting with the simple integration of this plugin, on trivial topic meaning imports, then build up from there, as everything is then possible. Yes its impossible to review this of course, as we have countless flaws, which is the natural outcome, when not having auto correction like this. Nobody can to this kind of job. Except for one. Once we have implemented, we do not need checkstyle anymore, as its 1 LOC activating ether eclipse custom config or google or palantir config, this is some detail the community needs to decide. Its not important to me, assuming nor for others, we only care about convention in general, not in detail, naturally evolving to auto fix. When having ability to control, code becomes fluid. One of you guys the will then just add 1 LOC activating the change. Then you check (locally) the pattern, as we can not check 1.200 header files in detail as discovered in:
As these changes are ALL about pattern they are "easy" to review as all the same. Humans maybe error prone, but master of disaster, tend to pattern and natural symmetry considering PI 3.1415926535..... You simply have to trust the tool it will execute itself and validate just like the maven build will fix itself. |
Beta Was this translation helpful? Give feedback.
-
the good thing is they are done one time only, then they are fixed by design/devinition. new feat incoming, as this would address a lot of flaws, ideally all, as spotless will check and apply all the time. |
Beta Was this translation helpful? Give feedback.
-
|
Its all related and spot the solution to all:
considering this a good PoC and realistic to merge. Then could increment from there even up to fully replacing checkstyle, automating all its features. |
Beta Was this translation helpful? Give feedback.
-
|
Whatever the code style we pick I want an Intellij config that will format the code to be compliant code. And Maven's CI profile should only check for compliance without changing any code. Ideally Maven wouldn't do any rewrite unless prompted explicitly. Maybe while we're at it we could have a git pre-commit setup that calls the formatter? Wdyt @adangel
If using Spotless is the solution to everything please stop opening new issues about it, we're already talking about it here. Let's discuss it here and stop dispersing. |
Beta Was this translation helpful? Give feedback.
-
This could be complex, as Spot takes some time, while committing is a fast and frequent task. Assuming every commit would then somehow execute Despite that, I’ve experienced in some projects that hooks failed to ensure Conventional Commits. They were installed in my Git but still not enforced. Yes, having it run in the cloud only makes sense for the We should be able to detect runs on a dev machine and only execute the This would also reduce the need for manual interaction by executing some dedicated profile. Quarkus build has a parameter Maven and Quarkus both deliver the fixes "out of the box," executed silently when passing the
This is very specific but understandable, assuming we all use IDEA. Its all there, we just need to use is. |
Beta Was this translation helpful? Give feedback.
-
|
maven does not apply auto fix on cloud like expected:
in gradle its one simple if and its done: if (System.env['CI'] == null) {
tasks.named('spotlessCheck') {
dependsOn 'spotlessApply'
mustRunAfter 'spotlessApply'
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to change this issue to a discussion topic and change the subject to "Improve Developer Experience". |
Beta Was this translation helpful? Give feedback.
-
Topic: License headers
|
Beta Was this translation helpful? Give feedback.
-
Topic: Switch to spotless or not?
Things to consider:
|
Beta Was this translation helpful? Give feedback.
-
Topic: import order inconsistenciesissue: import order is not consistent between IntelliJ IDEA / Eclipse / Checkstyle Config
What is the import order enforced by checkstyle currently? Groups:
What is the import order in the eclipse configuration currently? https://github.com/pmd/build-tools/blob/main/eclipse/pmd-eclipse-imports.importorder Groups:
What is the import order in the IntelliJ IDEA configuration currently? Groups:
What is the import order in the Netbeans configuration currently? https://github.com/pmd/build-tools/blob/main/netbeans/formatting.zip Groups:
not sure, where static imports would be here... |
Beta Was this translation helpful? Give feedback.
-
spotless:sortpom
|
Beta Was this translation helpful? Give feedback.
-
IDE agnostic configuration
@Pankraz76 We already have a codestyle. What's the problem with that codestyle? Is there something missing? your comment #5867 (comment) seems to expect some things, that are not defined in our codestyle yet. Also, if we use spotless, which tool makes sure, that the IDE configuration is aligned? (to be honest, in the end everybody is using some IDE) |
Beta Was this translation helpful? Give feedback.
-
Towards "convention over configuration"
@Pankraz76 I think, that is the core of your whole PRs/issues (and hence I named this whole discussion "Improve Developer Experience"). Is this correct? All the other topics here are probably only some small steps/parts, that help, but don't fulfill the vision fully. If you would need to write a contributors guide for PMD, what should it look like? In theory, our starting point is currently https://github.com/pmd/pmd/?tab=readme-ov-file#-contributing - that's the assumption, that anybody who wants to contribute is at least reading this section in the readme... |
Beta Was this translation helpful? Give feedback.
-
|
By the way, I don't remember you mentioning this: @Pankraz76 which IDE are you using actually? |
Beta Was this translation helpful? Give feedback.
-
|
PMD feels outdated compared to modern tools like Maven, Quarkus, and Spotless, which have moved beyond cumbersome configuration requirements for basic formatting. While I appreciate PMD as a tool, its insistence on manual whitespace configuration—rather than adopting modern conventions—makes it feel obsolete, especially when alternatives like Rewrite automate these tasks effortlessly. I don’t contribute much to PMD, not because I dislike it, but because its maintenance burden outweighs its benefits in its current state. That said, I still recognize PMD’s importance and believe it deserves an up-to-date build setup. The current configuration, which some defend, was effectively broken for seven years. Is this the quality standard we expect from an established tool? Instead of clinging to outdated practices, we should move decisively in the direction already set—automating what should be convention, not configuration. If we agree on the goal, why the delay? Let’s be strict and consistent in modernizing PMD rather than preserving inefficiencies. |
Beta Was this translation helpful? Give feedback.
-
yes, as we aim for but fixes as well, theres might gonna be an compromise to make, to achieve this. Maybe the plugin is possible to run only one file, like checkstyle does then it might be possible to have it similar. |
Beta Was this translation helpful? Give feedback.
-
|
Having the same eclipse formater config, we should be able to apply the same approach like open search. Effectively automating checkstyle, assuming the rule match.
|
Beta Was this translation helpful? Give feedback.
-
|
closing to stop starting start finishing. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Collections if things that can be improved ("what is itching you")
importOrderwithMaven Spotless Plugin#5776checkstyleburden imposed ontrimTrailingWhitespaceandremoveUnusedImportswithMaven Spotless Plugin#5848editorconfig.org-editorconfig-maven-plugin#5636 and [core] add IDE agnostic configuration #5651 and [core] add IDE agnostic configuration withMaven Spotless Plugin#5867/**and some with block-comment/*Tools/Config/Practices, that are currently used in PMD
mvn verifylocally ensures, everythings compliesTools/Config/Practices, that maybe offer improvements
Note: These need to be evaluated, whether we really want to use them...Do they offer so much more in comparison to the tools we already use?
Maven Spotless Plugin#5867)General considerations
Old info
Addressing the comment and issue of
people use a lot of editors and very different versions, which is a valid concern—one good approach to handling this is using Spotless.Applying a strictly enforced style can be challenging without a universal solution. Spot provides a way to apply the config out of the box, making it easier to maintain consistency.
This is very specific but understandable, assuming we all use IDEA.
Its all there, we just need to use is.
Beta Was this translation helpful? Give feedback.
All reactions