Interest check: standalone CLI

[timothysparg]

Before opening a large PR, I wanted to gauge whether this is something the project would consider accepting.

I've built a standalone CLI for spring-javaformat on a fork branch that exposes two commands:

• spring-javaformat format - applies formatting to source files
• spring-javaformat validate - checks that files conform to the style

The CLI is distributed as a native binary from Github Releases. See releases on the fork to see how this could look.

Motivation

The existing plugins serve projects that already use Maven or Gradle well. But there's a gap for workflows where neither is present or desirable: running a quick format check in a git hook, or any other situation where you don't want to setup the entire build ecosystem.

Implementation notes

The implementation lives in a new spring-javaformat-cli module and reuses the existing spring-javaformat-formatter core - no duplication of formatting logic.

Why picocli instead of Spring Shell? Staying within the Spring ecosystem would have required an outdated version of Spring Shell, or alternatively decoupling the CLI module from the shared dependency management of the rest of the project. Using Picocli sidesteps the issue quite neatly.

CI / build overhead: The native image build follows the conventions of the rest of the codebase, but tries to strike a balance on CI cost. On pull requests, only a single native image is built (Ubuntu). The full platform matrix is reserved for releases.

Commit breakdown

The PR is structured as 8 incremental commits that build up the CLI module step by step, with the intent of trying to make it easier to review

• Add spring-javaformat-cli module - Spring Boot + picocli skeleton targeting Java 17, with Error Prone and NullAway
• Add picocli command infrastructure - root command, CommandLineRunner, version provider
• Add file scanning infrastructure - InputOptions mixin, FileScanner, FileFormatterFactory
• Add apply subcommand - formats files in place, with integration tests
• Add check subcommand with JTE output rendering - validates formatting and Checkstyle rules, ANSI-coloured output via JTE templates, with integration tests
• Add native image support - GraalVM reflect-config.json and resource-config.json for Checkstyle, formatter, and Eclipse JDT types
• Add CI/CD workflows for native image builds and releases - 4-platform matrix (linux-amd64, linux-arm64, windows-amd64, macos-arm64) using Liberica NIK JDK 17; PR builds Linux only, full matrix on release
• Document the CLI - README coverage of installation via SDKMAN, apply, check, and available options

---

Happy to provide more detail, adjust the approach, or discuss trade-offs