quarkus — GitHub Copilot rule: what it does, how to install
Sets coding conventions for Quarkus applications in GitHub Copilot. Guides dependency injection, REST stack selection, and database testing.
.github/instructions/quarkus.instructions.mdWhat quarkus does
The rule triggers on Java files, build descriptors, and application properties whenever io.quarkus dependencies are detected. It instructs the assistant to use constructor injection and @ApplicationScoped beans. Code generation relies strictly on jakarta.* packages and Java records for DTO structures.
REST handling strictly separates Quarkus REST from RESTEasy Classic. Mixing both extensions breaks the build immediately, so the rule prevents accidental crossover in legacy projects. Persistence focuses on Hibernate ORM with Panache, database migrations using Flyway or Liquibase, and zero-config Dev Services instead of hardcoded hostnames.
Testing standards mandate @QuarkusTest paired with RestAssured, as well as mock replacement via @InjectMock. Integration test suites require running ./mvnw verify -DskipITs=false. For native compilation targets, reflection-heavy libraries must be registered explicitly using @RegisterForReflection.
What it helps with
- enforce constructor injection and jakarta packages in Quarkus CDI
- stop build failures caused by mixing Quarkus REST and RESTEasy Classic
- configure Panache repositories and Dev Services for local development
- run integration tests using RestAssured and proper Maven verify flags
Example prompts for the agent
- Create a Panache repository with paginated queries for active users
- Add an authenticated REST endpoint validated with Hibernate Validator
- Write a Quarkus integration test using RestAssured and @InjectMock
How to install quarkus
Manually: put the files in place
.github/instructions/quarkus.instructions.mdThe applyTo field sets which files it applies to
Manually: put the files in place
.claude/rules/quarkus.mdThe paths frontmatter field limits the files: move applyTo from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.cursor/rules/quarkus.mdcFrontmatter: description, globs, alwaysApply. Move applyTo from the source into globs, or the rule will not attach on its own
Manually: put the files in place
.devin/rules/quarkus.mdManually: put the files in place
.clinerules/quarkus.mdStep by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use
Questions about quarkus
How to install quarkus in GitHub Copilot?
Save the instruction file to .github/instructions/quarkus.instructions.md in the repository root. GitHub Copilot loads these guidelines automatically when editing matching Java and build files.
What does the quarkus rule do?
It guides the AI to use current Quarkus idioms, including typed configuration with @ConfigMapping, non-blocking event loops, and Panache persistence patterns.
Why does the rule restrict REST extensions?
Quarkus REST and RESTEasy Classic cannot coexist within the same application build. The rule instructs the assistant to detect the active stack and prevent incompatible extension pairs.
Source text
quarkus.instructions.md · MIT
--- applyTo: '**/*.java, **/application*.properties, **/application*.yml, **/application*.yaml, **/pom.xml, **/build.gradle, **/build.gradle.kts' description: 'Quarkus development standards and instructions' --- - Apply these instructions only when the project uses Quarkus (`io.quarkus` dependencies or the Quarkus Maven/Gradle plugin). - Check the project's existing Quarkus and Java versions (pom.xml, build.gradle, `quarkus.platform.version`) before suggesting changes; keep them unless asked to upgrade. For new projects target the recommended stream from https://code.quarkus.io/api/streams (3.40 at the time of testing; 4.0 is still beta) and Java 21+ (Java 17 minimum). Never hard-code a patch version in advice; use the Quarkus BOM. ## Dependencies and build - Add features through Quarkus extensions (`./mvnw quarkus:add-extension -Dextensions=...` or `quarkus extension add`), versions managed by the platform BOM. - Use Quarkus REST (`quarkus-rest`, `quarkus-rest-jackson`) for new projects and explicit migrations. In an existing RESTEasy Classic (`quarkus-resteasy*`) project keep that stack: the two are incompatible and mixing them fails the build. - Use `./mvnw quarkus:dev` (or `./gradlew quarkusDev`) for development; keep the Maven/Gradle wrapper. ## CDI and code - Use constructor injection; `@Inject` is optional on a single constructor. Avoid field injection in production code. - Prefer `@ApplicationScoped` beans; use `jakarta.*` imports only. - Use records for DTOs. Keep REST resources thin and delegate to services. - Use `@ConfigMapping` interfaces for grouped, typed configuration; `@ConfigProperty` for single values. Never hard-code secrets; use env vars or a secret store, and profiles (`%dev`, `%test`, `%prod`). - Use `quarkus.log.*` and JBoss Logging (or SLF4J) for logging. ## REST and validation - Return explicit status codes and map errors centrally rather than try/catch in each resource. In Quarkus REST projects use `RestResponse`/`Response`, `@ResponseStatus` and `@ServerExceptionMapper`; in RESTEasy Classic projects these are unavailable, so use Jakarta REST `Response` and an `ExceptionMapper` annotated `@Provider`. - Validate input with Hibernate Validator (`quarkus-hibernate-validator`, `@Valid`). - Add `quarkus-smallrye-health` and metrics (`quarkus-micrometer-registry-prometheus`, or another Micrometer registry extension; `quarkus-micrometer` alone exports nothing) for production services; expose them only to trusted networks. ## Data - Use Hibernate ORM with Panache (`quarkus-hibernate-orm-panache`); prefer the repository pattern (`PanacheRepository<T>`) for non-trivial domains, active record for simple ones. - Put `@Transactional` on service or resource methods that modify data; paginate list queries. - Manage schema with Flyway or Liquibase in production, not `drop-and-create`. - Rely on Dev Services for databases and brokers in dev/test; do not configure URLs for them in `%dev`/`%test`. ## Security - Use `quarkus-oidc` (or `quarkus-smallrye-jwt`) for authentication, and `@RolesAllowed`/`quarkus.http.auth.permission.*` for authorization. Secure endpoints by default. ## Testing - Use `@QuarkusTest` with RestAssured for application tests, `@QuarkusIntegrationTest` for packaged jar/native/container tests, and `@InjectMock` for CDI mocks. - Use Dev Services and `QuarkusTestResourceLifecycleManager` for external dependencies; use continuous testing in dev mode. - Run `*IT` tests with `./mvnw verify -DskipITs=false` (Failsafe; the generated pom sets `skipITs=true`), not `test`. Test artifacts are `quarkus-junit` (3.31+) or `quarkus-junit5` (older); keep what the project uses. ## Avoid - Reflection-heavy libraries without `@RegisterForReflection` when targeting native. - Blocking calls on the event loop (use `@Blocking` or virtual threads with `@RunOnVirtualThread`). - Swallowing exceptions or hard-coding configuration values. Upgrading Quarkus: run `quarkus update` (<https://quarkus.io/guides/update-quarkus>) and read the version's migration guide at <https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.20> (change the version) before editing.
© github · MIT · github/awesome-copilot