Migrate from Checkstyle to Spotless (#135)

* Migrate from Checkstyle to Spotless

* fix

* order

Author: loicgreffier

.checkstyle/checkstyle.xml

@@ -37,8 +37,8 @@ jobs:
           key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
           restore-keys: ${{ runner.os }}-m2
 
-      - name: Check style
-        run: mvn checkstyle:check
+      - name: Lint
+        run: mvn spotless:check
 
       - name: Build
         run: mvn clean package -P production

.github/workflows/pull_request.yml

@@ -36,8 +36,8 @@ jobs:
           key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
           restore-keys: ${{ runner.os }}-m2
 
-      - name: Check style
-        run: mvn checkstyle:check
+      - name: Lint
+        run: mvn spotless:check
 
       - name: Build
         run: mvn clean package -P production

.github/workflows/push_master.yml

@@ -1,13 +1,137 @@
-# Code of Conduct
+# Contributor Covenant Code of Conduct
 
-We want our project to be a welcoming and inclusive community for everyone. This code of conduct outlines our expectations for all contributors, as well as the consequences for unacceptable behavior.
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
 
 ## Our Standards
 
-We expect all contributors to:
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official email address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+the contact form available at
+[https://opensource.michelin.io](https://opensource.michelin.io)
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+
+[Mozilla CoC]: https://github.com/mozilla/diversity
+
+[FAQ]: https://www.contributor-covenant.org/faq
 
-- Be respectful and considerate towards others, regardless of their background, identity, or opinions.
-- Refrain from any form of harassment, discrimination, or hate speech.
-- Maintain a professional and respectful demeanor in all interactions within the project, including online and in person.
-- Be open to constructive feedback and willing to learn from others.
-- Respect the privacy of other contributors and users of the project.
+[translations]: https://www.contributor-covenant.org/translations

.checkstyle/HEADER renamed to .spotless/HEADER

@@ -1,62 +1,59 @@
 # Contributing to Suricate Widget Tester
 
-Welcome to our contribution guide! We're thrilled that you're interested in contributing to our project. This guide will help you understand the process and expectations for contributing, so that we can work together effectively and efficiently.
+Welcome to our contribution guide.
+This guide will help you understand the process and expectations for contributing.
 
 ## Getting Started
 
 ### Issues
 
-Issues should be used to report problems, request a new feature, or to discuss potential changes before a PR is created. When you create a new Issue, a template will be loaded that will guide you through collecting and providing the information we need to investigate.
+If you want to report a bug, request a feature, or suggest an improvement, please open an issue on the [GitHub repository](https://github.com/michelin/suricate-widget-tester/issues)
+and fill out the appropriate template.
 
-If you find an existing issue that addresses the problem you're having, please add your own reproduction information to the existing issue instead of creating a new one. Adding a [reaction](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) can also indicate to our maintainers that a particular problem is affecting more than just the reporter.
+If you find an existing issue that matches your problem, please:
+- Add your reproduction details to the existing issue instead of creating a duplicate.
+- Use reactions (e.g., 👍) on the issue to signal that it affects more users. [GitHub reactions](https://github.blog/news-insights/product-news/add-reactions-to-pull-requests-issues-and-comments/) help maintainers prioritize issues based on user impact.
 
-If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and a clear description, relevant information, and a code sample or executable test case demonstrating the expected behavior that is not occurring.
+If no open issue addresses your problem, please open a new one and include:
+- A clear title and detailed description of the issue.
+- Relevant environment details (e.g., version, OS, configurations).
+- A code sample or executable test case demonstrating the expected behavior that is not occurring.
 
 ### Pull Requests
 
-PRs are always welcome and can be a quick way to get your fix or improvement slated for the next release. In general, PRs should:
-
-- Only fix/add the functionality in question OR address wide-spread style issues, not both.
-- Add unit or integration tests for fixed or changed functionality (if a test suite already exists).
-- Address a single concern in the least number of changed lines as possible.
-- Be accompanied by a complete Pull Request template (loaded automatically when a PR is created).
-
-Be sure to use the past tense ("Added new feature...", "Fixed bug on...") and add tags to the PR ("documentation" for documentation updates, "bug" for bug fixing, etc.).
-
-For changes that address core functionality or would require breaking changes (e.g. a major release), it's best to open an Issue to discuss your proposal first. This is not required but can save time creating and reviewing changes.
-
-In general, we follow the ["fork-and-pull" Git workflow](https://github.com/susam/gitpr)
+To contribute to Suricate Widget Tester:
 
 - Fork the repository to your own GitHub account
 - Clone the project to your machine
-- Create a branch locally from master with a succinct but descriptive name
-- Commit changes to the branch
-- Following any formatting and testing guidelines specific to this repo
-- Push changes to your fork
-- Open a PR in our repository targeting master and follow the PR template so that we can efficiently review the changes.
+- Create a branch from the `master` branch
+- Make your changes and commit them to your branch
+- FPush your changes to your fork
+- Open a merge request to the `master` branch of the Suricate Widget Tester repository so that we can review your changes
 
 ## Style Guide
 
 ### Back-End
 
-We maintain a consistent code style using [Checkstyle](https://checkstyle.sourceforge.io/).
+We maintain a consistent code style using [Spotless](https://github.com/diffplug/spotless/tree/main/plugin-maven).
+For Java code, we follow the [Palantir](https://github.com/palantir/palantir-java-format) style.
 
-The configuration file is defined in the `.checkstyle` folder.
-To perform Checkstyle validation, run the following:
+To check for formatting issues, run:
 
 ```bash
-mvn checkstyle:check
+mvn spotless:check
 ```
 
-Before you start contributing new code, it is recommended to:
+To automatically fix formatting issues and add missing file headers, run:
 
-- Install the IntelliJ [CheckStyle-IDEA](https://plugins.jetbrains.com/plugin/1065-checkstyle-idea) plugin.
-- Configure the plugin to use Suricate Widget Tester's Checkstyle configuration file.
+```bash
+mvn spotless:apply
+```
 
 ### Front-End
 
 We maintain a consistent code style using [ESLint](https://eslint.org) and [Prettier](https://prettier.io).
 
-We use [Husky](https://typicode.github.io/husky/) and [Lint-Staged](https://github.com/lint-staged/lint-staged) to perform linting and formatting checks before committing.
+We use [Husky](https://typicode.github.io/husky/) and [Lint-Staged](https://github.com/lint-staged/lint-staged) to
+perform linting and formatting checks before committing.
 
 After the first `npm install`, everything should be set up automatically.