Add support for multiline query formatting in Query annotations

[catturtle123]

This PR addresses issue #1726

Summary

• Default Data Query Style Change: Changed the default query generation style to compact (single line) to ensure broader compatibility across Java versions.

• Architectural Refinement (Interface Separation): Decoupled the query formatting logic by introducing the QueryFormatter interface with dedicated implementations (JpqlQueryFormatter, MongoQueryFormatter). This allows for repository-specific formatting strategies.

• Robust String Escaping & Formatting:

• Integrated StringEscapeUtils.escapeJava() to safe-guard generated queries against syntax errors.

• Multiline Indentation: Improved Text Block generation by adding proper indentation/alignment to ensure the generated query is visually consistent with the surrounding Java code.

• Configuration & Fallback: Updated logic to use compact and multiline keywords from UserSettings. Implemented a fallback mechanism that defaults to compact and triggers a log.warn for invalid or null inputs.

Key Changes

• Refactoring & Logic:

• QueryFormatter.java, JpqlQueryFormatter.java, MongoQueryFormatter.java: Separated formatting logic into an interface-based structure.

• BootJavaConfig.java: Updated style selection and added validation/fallback logic.

• DataRepositoryAotMetadataCodeLensProvider.java: Refactored to prioritize safety and proper indentation.

• Test Suite Updates:

• QueryMethodCodeActionProviderJpaTest.java & QueryMethodCodeActionProviderMongoDbTest.java: Updated to verify the output specifically for the compact style.

• DataRepositoryAotMetadataCodeLensProviderTest.java: Added comprehensive test cases for both compact and multiline styles, verifying correct indentation.

Resolved Issues

• Fixed Syntax Errors: Resolved IndexOutOfBoundsException by properly escaping special characters.
• Visual Alignment: Multiline queries now include appropriate leading spaces, improving the aesthetics of the generated code.
• Error Resilience: Prevents IDE tool failure by falling back to a safe default when configuration is missing or malformed.

Discussion Points

• Test Coverage Asymmetry: Currently, DataRepositoryAotMetadataCodeLensProviderTest provides full coverage for both styles. However, QueryMethodCodeActionProviderJpaTest and QueryMethodCodeActionProviderMongoDbTest are currently limited to verifying the compact style. Should I expand these two classes to include multiline test cases as well to maintain consistency?
• Fallback Strategy: Is the use of log.warn followed by a fallback to compact an acceptable approach for handling unexpected user configuration values? (Silent fallback to compact for null cases (no log.warn).)

Test

[martinlippert]

I tried the latest version here and I do see the multiline preference working and slitting up the query statement nicely into multiple lines. But I do not see (yet) the correct formatting. Am I missing something?

[catturtle123]

I tried the latest version here and I do see the multiline preference working and slitting up the query statement nicely into multiple lines. But I do not see (yet) the correct formatting. Am I missing something?

Thanks for trying it out! Yes, the multiline splitting itself is working — the query string gets broken into multiple lines correctly.

The formatting (indentation) issue is what I'm working on now. I actually got it working in VSCode first — the "Add Query" CodeAction triggers IDE auto-formatting, so the indentation comes out correctly there.

But then I realized this approach doesn't carry over to Eclipse. So I'm rethinking the approach — specifically how to handle formatting for the "Turn into Query" CodeLens path, since that uses workspace/applyEdit which doesn't automatically trigger IDE formatting on either side. I've got the Eclipse preference/settings wired up, but now I need to figure out how to trigger the IDE's formatter after the edit is applied so the indentation gets properly adjusted.

Working on it — will update once I have a solution that works for both VSCode and Eclipse.

[BoykoAlex]

@catturtle123 For the IDE formatting I'd chain another command to the code action: the first add a query and the second performs the formatting. See package org.springframework.tooling.ls.eclipse.commons.commands in the org.springframework.tooling.ls.eclipse.commons plugin project in the spring-tools. It has examples of commands we've introduced for the eclipse side that we can execute from the LS. The plugin.xml has contributions of these commands into eclipse command/handler framework. There is definitely a command to format selection in the editor in Eclipse that exists already... you'd haveto find a way to bridge to it properly.
Another way to solve this would be from the OpenRewrite recipe side. The AddAnnotationOverMethod has autoFormat call however it uses the default (intelij style) formatting. Instead it should use the same formatting as the file uses. I heard OpenRewrite is able to detect the formatting of the code base and have it as marker somewhere to use in autoFormat calls. The format detection bit is missing at the moment... (I'd like to have a look at why it is missing as well)

[BoykoAlex]

@catturtle123 I've tried formatting via OpenRewrite snippet auto-format (#1775) via the recipe used to add a query. Added styling markers to parsed sources. The version of Rewrite we used didn't format string block. I've upgraded to the latest version of OpenRewrite and there is block string formatting but it's somewhat unexpected.
Therefore the command for Eclipse remains to do... There seems to be org.eclipse.ui.edit.format command but it needs a selection in the editor... Formatting should be available on the via the eclipse SourceViewer class via operation API (but I'd have to refresh my memory on that) and that likely takes the range rather than the selection.

[BoykoAlex]

(Or maybe rebase and see how it looks. I can see the rationale behind rewrite's string block formatting)

[BoykoAlex]

@martinlippert @catturtle123 I think I like the Rewrite's formatting for block string literals. I think it is better than what JDT produces actually. Maybe we can stop here with query split into multiple lines as Rewrite's recipe would format the string block quite well. We can continue looking into the formatting on the client but it'd mean another command which means 2. commands to undo... The formatting on the client would make more sense once we drop Rewrite in favour of JDT for quick fixes which is not too far out actually... so not sure...