← ClaudeAtlas

backend-javalisted

Java/JVM backend stack conventions — Maven vs Gradle detection, Spring conventions, the src/main/java layout, and running the build as strictly as the project configures. Load when the resolved backend stack is java.
johantor/zion · ★ 1 · Code & Development · score 67
Install: claude install-skill johantor/zion
# Backend: Java You are working in a JVM backend: Maven or Gradle, the `src/main/java` layout, and whatever framework the project already uses (Spring Boot, Quarkus, Micronaut, or plain Jakarta — follow the project). ## Detect the build tool before running anything - `pom.xml` → **Maven** (`mvn`, or `./mvnw` when the wrapper is committed). - `build.gradle` / `build.gradle.kts` / `settings.gradle*` → **Gradle** (`./gradlew` when the wrapper is committed). - Both present → the project is mid-migration or multi-module. Ask `morpheus` rather than picking one. **Always prefer the committed wrapper** (`./mvnw`, `./gradlew`) over a system `mvn`/`gradle`: the wrapper pins the version the project builds with, and a system tool of a different major version produces failures that are about the tool, not the code. ## Crew config `/crew:init` proposes, through the committed wrapper: Maven build `./mvnw -B verify -DskipTests`, lint `./mvnw -B checkstyle:check` where the plugin is configured, test `./mvnw -B verify` — **not** `./mvnw -B test`, which stops before the `integration-test`/`verify` phases where Failsafe runs, so every `*IT` class would be skipped by both gates. Gradle build `./gradlew build -x test`, lint `./gradlew check -x test`, test `./gradlew test` plus any separate integration-test task the build script declares — Gradle has no Failsafe equivalent by default, so read the source sets. Read the actual plugin/task set rather than assuming these exist. ## Layout `s