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. ## Hard rules ### Versions live in exactly one place - **Dependency versions and scopes**: only in the **root** `pom.xml` under `<dependencyManagement>`. A module may say one thing about a managed dependency — a *narrower* scope, where two modules genuinely want different ones (`enforcer-api` is managed `provided` and narrowed to `test` by `adopt`; `jsoup` is managed unscoped and narrowed to `test` by `claude-code-enforcer`). - **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. The exceptions are reactor artifacts, which use `${project.version}`. - **Artifacts that must move together share one property**, not a version each: `protobuf.version` (runtime *and* `protoc`), `grpc.version`, `derby.version`, `log4j2.version`, `maven.api.version`. `derby.version` and `log4j2.version` are Spring Boot's own property names, so overriding them also moves the siblings the `spring-boot-dependencies` BOM manages (derbyshared, the other log4j2 artifacts) instead of leaving them on Boot's older version. ### Ask before adding a dependency - Use t