Format GitHub action

[gcatanese]

Add Maven Spotless Maven plugin to format the generated code.

Checkstyle configuration has been adjusted to align with Spotless formatting rules.

[gemini-code-assist]

Hello @gcatanese, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini here, providing a summary of this pull request to help everyone get up to speed quickly. The main goal of this PR, as indicated by the title and description, is to introduce automated code formatting into the project. This is achieved by adding the Spotless Maven plugin to the build process. To ensure consistency, the existing Checkstyle configuration has been modified slightly to align with the formatting rules enforced by Spotless, specifically the Google Java Format style.

Highlights

• Add Spotless Maven Plugin: The spotless-maven-plugin has been added to the pom.xml to automate code formatting for Java files.
• Configure Google Java Format: Spotless is configured to use the Google Java Format (version 1.19.2) with the GOOGLE style, including formatting Javadoc and removing unused imports.
• Adjust Checkstyle Configuration: The checkstyle.xml file has been updated to disable the WhitespaceAround rule, which was conflicting with the formatting applied by Google Java Format via Spotless.

Changelog

• checkstyle.xml
  • Commented out the WhitespaceAround module to avoid conflicts with Spotless/Google Java Format.
• pom.xml
  • Added the spotless-maven-plugin to the <build><plugins> section.
  • Configured Spotless for Java files (src/main/java and src/test/java).
  • Specified googleJavaFormat with version 1.19.2 and GOOGLE style.
  • Enabled Javadoc formatting and removal of unused imports via google-java-format.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

Code flows like a stream,
Spotless makes it a clean dream,
Format, build, release.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively introduces the Spotless Maven plugin to automate code formatting using the Google Java Style. This is a commendable step towards maintaining consistent code quality and readability across the project. The configuration for Spotless is well-defined, including the use of recent plugin versions, specific includes, and enabling Javadoc formatting.

The adjustment to the Checkstyle configuration to disable the WhitespaceAround rule is also a sensible change, as Spotless (configured with Google Java Style) will now handle this aspect of formatting, preventing potential conflicts or redundant checks.

My main suggestion focuses on enhancing the build process by integrating an automated formatting check into the Maven lifecycle, which would further strengthen the enforcement of coding standards.

Summary of Findings

• Spotless Build Lifecycle Integration: The current Spotless setup enables manual code formatting. A suggestion was made to enhance this by adding a spotless:check goal to the Maven build lifecycle (e.g., to the validate or verify phase). This would automatically verify code formatting during builds (like in CI) and fail the build if inconsistencies are found, thereby ensuring consistent code style across all contributions.

Merge Readiness

The pull request is well-structured and introduces a valuable tool for maintaining code quality. The core functionality of adding Spotless for code formatting is correctly implemented.
The suggestion to integrate spotless:check into the build lifecycle is aimed at further improving the robustness of the formatting enforcement and is offered for your consideration.

I am unable to approve the pull request directly. However, pending consideration of the feedback, the changes appear beneficial and should be ready for merging after any desired adjustments and final approval from the project maintainers.

[gemini-code-assist]

The current Spotless configuration defines an apply goal, which allows developers to manually format code by running mvn spotless:apply. This is very useful.

To further ensure that all code committed to the repository adheres to the defined style, it's a common and beneficial practice to also integrate an automated check into the build lifecycle. You could add a spotless:check execution bound to a phase like validate or verify.

This setup would:

1. Allow developers to run mvn spotless:apply to format their code locally.
2. Cause the build (e.g., in CI or pre-commit hooks) to fail if mvn spotless:check detects unformatted code, thus enforcing the standard before code is merged.

What are your thoughts on adding such a check to the build process to automatically verify formatting adherence?

                <executions>
                    <execution>
                        <!-- This execution allows manual formatting via 'mvn spotless:apply' -->
                        <id>spotless-apply-manual</id>
                        <goals>
                            <goal>apply</goal>
                        </goals>
                    </execution>
                    <execution>
                        <!-- This execution checks formatting during the 'validate' phase of the build -->
                        <id>spotless-check</id>
                        <phase>validate</phase> <!-- Or consider the 'verify' phase -->
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>