First off, thank you for considering contributing to Moo! It's people like you that make Moo such a great tool for the community.
This document provides guidelines and standards for contributing to this project. Following these helps us maintain a high-quality, high-performance codebase.
By participating in this project, you are expected to uphold our Code of Conduct. Please report unacceptable behavior to the project maintainers.
-
Fork the repository on GitHub.
-
Clone your fork locally:
git clone https://github.com/YOUR_USERNAME/twitter-backend-java.git cd twitter-backend-java
- JDK: Ensure you have Microsoft Build of OpenJDK 21 installed.
- Maven: Use the provided wrapper
./mvnw. - Database: Local MySQL or H2 (configured via profiles).
- IDE: IntelliJ IDEA is recommended (Google Java Format plugin encouraged).
To keep the codebase clean and stable, we enforce the following rules:
-
We use Spotless with Google Java Format.
-
Always format your code before committing:
./mvnw spotless:apply
-
The CI will fail if the code is not perfectly formatted.
- Rule: Never use fully qualified package names inline (e.g.
java.util.List). - Action: Always use
importstatements at the top of the file.
- Every Service and Repository method must be annotated with JSpecify.
- Use
@Nullablefor optional return types or parameters. - Use
@NonNullfor mandatory values. - Default to
@NonNullunless there is a valid reason for nullability.
- Layering: strictly follow
Controller->Service->Repository. - Models (DTOs): Never expose JPA Entities directly in Controllers. Use
Modelclasses andMapperutilities. - Validation: Use
jakarta.validationconstraints (@NotBlank,@Size, etc.) on all Models. - Scalability: Always use
Pageablefor list endpoints. ReturningList<T>is strictly prohibited for feed-based APIs.
- Use the
Principalobject in Controllers to identify the authenticated user. - Never use
UUID.randomUUID()or hardcoded IDs for "current user" logic.
-
Branch Naming:
- Features:
feature/short-description - Bug Fixes:
fix/issue-id-description - Chores/Docs:
chore/description
- Features:
-
Commit Messages:
- Use conventional commits (e.g.,
feat: ...,fix: ...,docs: ...). - Keep messages concise but descriptive.
- Use conventional commits (e.g.,
-
Rebasing:
- Always rebase your feature branch against the latest
masterbefore submitting a PR.
- Always rebase your feature branch against the latest
-
Unit Tests: Mandatory for all new logic in the
servicelayer. -
Integration Tests: Required for new API endpoints.
-
Coverage: Aim for high coverage. Ensure
mvn jacoco:reportshows no regressions. -
Run all tests locally before pushing:
./mvnw test
To respect the time of our maintainers, a Pull Request will not be reviewed until the following conditions are met:
- DCO Compliance: Every commit must be signed-off (
git commit -s). - Green CI: The
PR Checkerworkflow must pass successfully on GitHub. - No Conflicts: The PR must be rebased against the latest
master.
If your PR is missing sign-offs, you can fix it using:
git rebase HEAD~N --signoff (where N is the number of commits).
-
Update Documentation: If you add or change an API, ensure the Swagger/OpenAPI metadata is updated.
-
Self-Review: Go through your changes and ensure no "TODOs" or debug logs are left behind.
-
Assign Reviewers: Assign at least one maintainer for review once the CI is green. Be responsive to feedback!
By contributing, you agree that your contributions will be licensed under the GNU Affero General Public License v3.0.