maven-conventionslisted

# Maven Conventions Skill Keep `pom.xml` edits and build commands consistent with how the `tools` multi-module reactor is wired. Getting versions in the wrong place, or missing a profile, is the most common source of avoidable build friction here. ## When to Use - Editing any `pom.xml` - Adding or upgrading a dependency or a Maven plugin - Choosing which `mvn` command / profile to run - The user says "add a dependency" / "bump a version" / "the build fails" ## Hard rules ### Versions live in exactly one place - **Dependency versions and scopes**: only in the **root** `pom.xml` under `<dependencyManagement>`. - **Plugin versions**: only in the **root** `pom.xml` under `<pluginManagement>`. - **Module poms reference dependencies and plugins WITHOUT versions.** Never add a `<version>` to a module pom — add or change it in the root instead. ### Ask before adding a dependency - Use the existing Maven dependencies. **Always ask the user before adding a new one.** If approved, declare it (with version) in root `<dependencyManagement>`, then reference it version-free in the module. ### Clean after removing a code-generation source - Run `clean` after deleting a codegen input, so stale generated builders in `target/` cannot mask the change. ## Build commands (run from the repo root) | Command | Purpose | |---|---| | `mvn clean install` | Full clean build + install to local repo | | `mvn install` | Faster incremental build | | `mvn -pl <module> test` | Tests for a s