dashorst opened a new issue, #1867: URL: https://github.com/apache/wicket/issues/1867
Wicket has a code style (tabs, braces on their own line, 100 columns), but nothing in the build applies or checks it. The Eclipse formatter settings exist in two places: `wicket-eclipse-settings/files/org.eclipse.jdt.core.prefs`, released separately as the `wicket-eclipse-settings` artifact (version 4) and pulled in by the root pom, and `wicket-core/EclipseCodeFormat.xml`, an older exported profile. IntelliJ users have no profile at all. As a result formatting drifts with every contributor's IDE, reviews pick up whitespace noise, and contributors — human or tool-assisted — have no way to check their change matches the house style before submitting it. ## Proposal Enforce a single formatting standard in the Maven build with [Spotless](https://github.com/diffplug/spotless/tree/main/plugin-maven) (or a comparable formatter plugin if it turns out to fit better), with the formatter profile derived from the code as it is today, so that the first `spotless:apply` changes as little as possible. 1. **Distill the profile from the code base.** Start from the existing Eclipse settings, run the Eclipse JDT formatter (which Spotless can drive directly with an Eclipse XML profile) over the whole tree, and tune the settings that cause the largest diffs until the remaining changes are genuine inconsistencies rather than profile mismatches. Report the resulting diff size per module so the trade-offs are visible. 2. **One source of truth.** Keep a single canonical profile in the repository, used by Spotless. Retire or regenerate `wicket-core/EclipseCodeFormat.xml` and decide what happens to the `wicket-eclipse-settings` artifact (regenerate from the canonical profile, or drop it). 3. **IDE profiles.** Ship an Eclipse formatter profile and an IntelliJ code style scheme (IntelliJ can import the Eclipse XML, or use the Eclipse Code Formatter plugin; a native `.idea` code style may still be preferable) that produce the same output as the build. Consider an `.editorconfig` for the basics (indentation, line endings, final newline) for other editors. 4. **Build integration.** Run `spotless:check` in the regular build (and therefore in CI), with `spotless:apply` documented for contributors. Use `ratchetFrom` or an equivalent if we want to enforce only on changed files before the bulk reformat lands. 5. **Scope beyond Java.** Decide whether to also cover import order, the license header (now checked by apache-rat only for presence), poms (sortpom is already enforced by the pedantic pom enforcer, so avoid two tools fighting over the same file), and JavaScript/CSS/markup. Java first is fine. 6. **Bulk reformat.** Apply the formatter in a single, formatting-only commit and add its hash to `.git-blame-ignore-revs` so `git blame` stays useful. Do this on `master`; whether and when to do the same on `wicket-11.x` and `wicket-10.x` is a separate decision, since reformatting maintenance branches makes cherry-picks from `master` harder until they are reformatted too. 7. **Documentation.** Update the contributor documentation (README / AGENTS.md / user guide) to describe the style, the IDE setup and the `spotless:apply` step. ## Acceptance criteria - `mvn verify` fails on misformatted Java sources, with a message pointing at `mvn spotless:apply`. - The formatter profile lives in the repository and the Eclipse and IntelliJ profiles produce output identical to the build on the whole tree. - The bulk reformat commit is formatting-only and listed in `.git-blame-ignore-revs`. - The size of that reformat diff is reported in the pull request, together with the settings chosen to keep it small. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
