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

[AndreasIgel]

Summary

Resolves #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.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[AndreasIgel]

All of them is available in context right? But just replacing 3 parameters by context is not enough. Context should replace the member variables here too. Idee is to have less getter and not to add getlogger or other new getters to context

[igel-devin-ai]

RoasterCodeGenerator now stores only ProcessingContext. Logging, performance phases, source-file creation, type lookup, and formatter creation go through narrow context operations; no raw logger/environment/profile getters were added.

[AndreasIgel]

Here is still a simple builder prefix. Do we need this? Is it not logged below execution of simple builder and does this warning not lead to an abort of code generation?

[igel-devin-ai]

Removed the redundant simple-builders: prefix from formatter warnings. The warning does not abort generation: it explicitly reports the fallback, first to the bundled profile and ultimately to lightweight formatting if no profile is available.

[AndreasIgel]

Here again with simple-builder prefix. Do we do that always on warnings? And if this is the case, should it not be part of warning function instead of being repeated?

[igel-devin-ai]

Removed the formatter-specific prefixes for consistency with other ProcessingLogger warning callers. I did not move a prefix into ProcessingLogger because that would change all warnings globally and existing callers currently provide plain contextual messages.

[AndreasIgel]

More precisely, it has not been found in the configuration file of class path!?

[igel-devin-ai]

Made the bundled case more precise: it now says Bundled Eclipse formatter profile resource ... was not found on the processor classpath. The configured-profile message still distinguishes lookup as a filesystem path or classpath resource.

[AndreasIgel]

Is it usually to have an exception without message? And if this is the case, what about the cause or more text then just the class name. And function should be renamed from "describe"

[igel-devin-ai]

Renamed describe to getExceptionDetails. It now always includes the exception class, includes a nonblank message when present, and appends distinct root-cause class/message details. Message-less exceptions therefore still produce useful output.

[AndreasIgel]

Would nit be assertFalse be better here and nit using "!"? Or even better is there no assert for not containing?

[igel-devin-ai]

Changed this and the other equivalent checks to assertFalse(...contains(...)) for direct readability.

[AndreasIgel]

Could we have a helper method for this kind of assert or do we not already have one?

[igel-devin-ai]

Added CapturingProcessingLogger.assertMessageMatching(Predicate<String>, String) and use it here. The helper provides the expected description plus all captured messages on failure.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
89.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud