2.4 KiB
Repository Guidelines
Project Structure & Module Organization
Backend sources sit in src/main/java, anchored by de.assecutor.emulatorstation.Application. Core business logic lives under .../base/domain and UI components in .../base/ui/**, while lightweight DTOs reside in .../pojo. Shared helpers use the top-level util package; keep new utilities there if they cross module boundaries. Vaadin client assets are in src/main/frontend; generated files stay in generated/, custom theme assets in themes/default. Internationalization bundles belong in src/main/bundles, and configuration files in src/main/resources.
Build, Test, and Development Commands
Run the app locally with ./mvnw spring-boot:run (serves the Vaadin UI with live reload). Use ./mvnw vaadin:prepare-frontend after dependency upgrades to regenerate Flow metadata. Perform a full build with ./mvnw clean package, or ./mvnw -Pproduction clean package for an optimized artifact. Execute unit tests via ./mvnw test. Apply code formatting using ./mvnw spotless:apply.
Coding Style & Naming Conventions
Java formatting is enforced by Spotless + the bundled eclipse-formatter.xml; commit only formatted code (4-space indentation, braces on the same line). Stick to the de.assecutor.emulatorstation.* package hierarchy and CamelCase class names with lowerCamelCase members. TypeScript and theme resources follow Prettier rules from .prettierrc.json; run the linter via Spotless before committing. Keep Spring components annotated explicitly (@Service, @Route, etc.) for clarity.
Testing Guidelines
Adopt JUnit 5 for unit tests under src/test/java, mirroring the production package tree. Name pure unit tests *Test and integration tests *IT; the latter run through the integration-test Maven profile and may leverage Testcontainers. Add ArchUnit rules for architectural policies when touching base packages. Aim for coverage of business branches and Vaadin view logic; provide mock data for H2-backed repositories.
Commit & Pull Request Guidelines
Recent history favors short one-word summaries; build on that by writing concise, descriptive titles (≤50 chars) followed by optional detail in the body. Reference Jira or GitHub issues with #123 when relevant. For pull requests, include: purpose, testing notes (./mvnw test output), and UI screenshots whenever a view changes. Keep PRs focused per feature or bug to simplify review.