f91604aea6
- Update .gitignore to include additional build outputs and IDE files. - Modify pom.xml to add new plugin versions and configurations for frontend and OpenAPI TypeScript client generation. - Introduce project guidelines in roleplay-project.mdc, detailing architecture, coding standards, and testing practices. - Add initial documentation for the RolePlay concept and specifications. - Implement catch-all JAX-RS resource for serving the React application and establish API base path in application.yml. - Create foundational web components and TypeScript configuration for the frontend application.
70 lines
2.8 KiB
Plaintext
70 lines
2.8 KiB
Plaintext
---
|
||
description: RolePlay project context, architecture, and coding standards (Java/Quarkus, Maven, frontend)
|
||
alwaysApply: true
|
||
---
|
||
|
||
# RolePlay – Project Instructions
|
||
|
||
## Project context
|
||
|
||
- **Project**: RolePlay
|
||
- **Java**: 21
|
||
- **Build**: Maven
|
||
- **Framework**: Quarkus (latest stable)
|
||
- **GroupId**: de.neitzel | **ArtifactId**: roleplay
|
||
- **Base package**: `de.neitzel.roleplay`
|
||
- **Sub-packages**: `business`, `common`, `data`, `fascade`
|
||
- Startup code lives in the base package.
|
||
- **DB migrations**: Liquibase; scripts in `src/main/resources/db/migration`.
|
||
|
||
## Architecture and package rules
|
||
|
||
- **Startup/bootstrap**: `de.neitzel.roleplay`
|
||
- **Business logic**: `de.neitzel.roleplay.business`
|
||
- **Shared utilities, cross-cutting types**: `de.neitzel.roleplay.common`
|
||
- **Persistence / data access**: `de.neitzel.roleplay.data`
|
||
- **External-facing facades (REST, API)**: `de.neitzel.roleplay.fascade`
|
||
- Keep clear package boundaries; avoid circular dependencies.
|
||
|
||
## Coding standards (Java)
|
||
|
||
- Use Lombok to reduce boilerplate where it helps.
|
||
- Prefer immutability: `final` fields, constructor injection.
|
||
- Use Quarkus idioms; avoid heavyweight frameworks.
|
||
- Keep methods small and focused; one responsibility per class.
|
||
- Use Java 21 features when they improve clarity.
|
||
- Add concise comments only for non-obvious logic.
|
||
- All classes, fields, and methods (including private) must have JavaDoc describing purpose and usage.
|
||
|
||
## Testing
|
||
|
||
- Add or update unit tests for new or changed logic.
|
||
- Use JUnit 5 and Mockito; Arrange–Act–Assert; keep tests deterministic.
|
||
- Mock external dependencies; add integration tests only when requested.
|
||
|
||
## Maven and dependencies
|
||
|
||
- Target Java 21 in the Maven toolchain.
|
||
- Use the latest stable Quarkus platform BOM.
|
||
- Keep dependencies minimal; no new libraries without need.
|
||
- Keep versions up to date (especially for security).
|
||
- Put plugin and dependency versions in the `properties` section of `pom.xml`.
|
||
- Use `quarkus-maven-plugin` for build/run; `maven-surefire-plugin` for tests (JUnit 5); `maven-compiler-plugin` with Java 21.
|
||
|
||
## Frontend (React / Vite)
|
||
|
||
- Frontend lives under `src/main/web` (React, TypeScript, Vite, MUI).
|
||
- OpenAPI TypeScript client is generated into `src/main/web/src/api/generated/` by Maven (`mvn generate-sources`); do not edit by hand.
|
||
- Production build output: `target/web-dist`; copied to `META-INF/resources` by `maven-resources-plugin` for the Quarkus SPA.
|
||
|
||
## Do and don’t
|
||
|
||
- **Do**: keep code in the correct package; add tests for business logic.
|
||
- **Don’t**: put startup code outside the base package; add unnecessary abstraction layers.
|
||
|
||
## Output expectations
|
||
|
||
- Provide complete, compilable code with package declarations and imports.
|
||
- Prefer Quarkus-friendly APIs and annotations.
|
||
- When adding or changing logic, update or add unit tests.
|