Support external Eclipse formatter profile via -Asimplebuilder.formatterProfile (#278)

[devin-ai-integration]

Summary

Resolves java-helpers#278: the JDT formatter profile used for generated builders can now be replaced per project instead of being hard-wired to the bundled eclipse-java-format.xml.

New project-wide compiler option (no annotation override, as scoped in the issue):

-Asimplebuilder.formatterProfile=<file path | classpath resource>

Resolution in RoasterSourceFormatter.loadFormatterProperties():

if no custom profile configured      -> loadBundledProfile()
else loadConfiguredProfile(location)  // regular file first, then classpath resource; warns "…falling back to the bundled profile"
       .orElseGet(loadBundledProfile) // warns "…not found on the processor classpath"; empty Properties
                                      //   -> existing "JDT requested but profile unavailable" lightweight fallback

Both are built on a shared readProfile(location); the path is used as given (no placeholder substitution — ${project.basedir} in the Maven example is interpolated by Maven before javac runs).

Plumbing: CompilerArgumentsEnum.FORMATTER_PROFILE → ProcessingContext.getFormatterProfile() (trimmed, null = default) → RoasterCodeGenerator(ProcessingContext) (now the single constructor; the context gained getProcessingEnvironment()/getLogger()) → RoasterSourceFormatter(logger, mode, formatterProfile) (3-arg ctor now public, blank → default).

Behavior change to note: a missing custom profile previously (via the package-private test ctor) degraded to lightweight formatting; now it falls back to the bundled profile with a warning, so JDT formatting stays on. Two RoasterSourceFormatterTest cases asserting the old lightweight degradation were replaced by constructor_missingProfile_fallsBackToBundledProfile; the "profile unavailable → lightweight" path now only triggers when the bundled resource itself is absent.

Tests: filesystem profile (tab-indent variant of the bundled XML, asserts tabs in output vs spaces for default), explicit classpath name, missing path, blank value, malformed XML, CompilerArgumentsReader read, and an end-to-end compilation with -Asimplebuilder.formatterProfile=<tempfile> in ConfigurationProcessingTest. Documented under formattingMode in docs/CONFIGURATION.md.

Full processor suite: 423 tests green; example module regenerates byte-identically.

Link to Devin session: https://app.devin.ai/sessions/d691231fba0842a4b842b275ca4b35ed
Open in Devin Desktop: https://app.devin.ai/desktop/session/d691231fba0842a4b842b275ca4b35ed?variant=devin
Requested by: @AndreasIgel

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[AndreasIgel]

Is ${project.basedir} really supported here? I would have expected, that a path (relative or absolute) would be needed here and the processor would not interpret an environment variable

[devin-ai-integration]

You're right that the processor does no placeholder substitution — it uses the string as given (file path first, then classpath resource). ${project.basedir} works in the example only because Maven interpolates it inside pom.xml before javac is started, so the processor receives an absolute path. Clarified that in the docs in 2e1b3a8 (and that relative paths resolve against javac's working directory).

[AndreasIgel]

Instead of adding a new parameter here, does context contain the processingEnv or code versa? So just giving one of both into constructor?

[devin-ai-integration]

Good point — ProcessingContext already holds the ProcessingEnvironment, logger, performance tracker and now the formatter profile. Done in 2e1b3a8: RoasterCodeGenerator has a single constructor RoasterCodeGenerator(ProcessingContext); added getProcessingEnvironment()/getLogger() to the context and updated the resilience test accordingly.

[AndreasIgel]

Please put the creation of a formatting profile into separate line or onto a helper function

[devin-ai-integration]

Done in 2e1b3a8: getFormatter now uses computeIfAbsent(mode, this::createFormatter) with a dedicated createFormatter(FormattingMode) helper.

[AndreasIgel]

Having selector booleans in function calls is an antipattern right?

[devin-ai-integration]

Agreed. Done in 2e1b3a8: the boolean is gone — loadFormatterProperties now branches once on whether a custom profile is configured and delegates to loadConfiguredProfile(location) (warns "…falling back to the bundled profile") / loadBundledProfile() (warns "…not found on the processor classpath"), both built on a shared readProfile(location).

[AndreasIgel]

moved to java-helpers#284