jvm-dependency-triage

Diagnose JVM dependency version conflicts, wrong scopes, and unsafe bumps with Gradle, Maven, and Bazel commands.

Updated Aug 13, 2026
One-click install
npx skills add https://github.com/ocx-sh/grimoire-lore --skill jvm-dependency-triage-ocx-sh
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: jvm-dependency-triage
Source: https://github.com/ocx-sh/grimoire-lore/tree/main/skills/jvm-dependency-triage
Command: npx skills add https://github.com/ocx-sh/grimoire-lore --skill jvm-dependency-triage-ocx-sh

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? JVM builds resolve dependency versions through mechanisms (conflict resolution, constraints, dependencyManagement, mediation) that differ between Gradle, Maven, and Bazel, so agents and developers routinely misdiagnose why a version was selected, misplace a declaration, or ship a version bump whose transitives nobody inspected. This Skill provides an evidence-first triage procedure that names the selecting mechanism, the exact file and line to fix, and the command whose output changed. ## Core Features & Use Cases - Version conflict triage: Uses dependencyInsight, dependency:tree -Dverbose, and help:effective-pom to identify whether conflict resolution, a constraint, a platform, a force, or dependencyManagement selected a version, and where the fix belongs. - Declaration correctness checks: Detects api vs implementation leaks, compileOnly runtime traps, enforcedPlatform() and strictly misuse in published libraries, and unbound maven-enforcer-plugin executions. - Safe version bumps: Resolves candidate coordinates against the real repository before writing them down, carries lockfiles and verification-metadata diffs, and blocks dynamic versions (-SNAPSHOT, +, ranges) in release builds. - Use Case: A Dependabot PR bumps Guava and the build passes. Run entry point 3 to resolve the coordinate, diff dependencyInsight output on both sides of the change, and regenerate lockfiles with a reviewed verification-metadata diff before approving. ## Quick Start Ask the agent to triage why com.google.guava:guava resolved to an unexpected version in this repository using the jvm-dependency-triage procedure.

Frequently Asked Questions about jvm-dependency-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find why Gradle resolved a different dependency version?▼

Run ./gradlew :module:dependencyInsight --configuration runtimeClasspath --dependency group:artifact to see the selection reason. The output distinguishes conflict resolution, constraints, platforms, and forces, and each points to a different fix location.

How does Maven dependency mediation differ from Gradle conflict resolution?▼

Maven mediation picks the nearest definition by tree depth with first-declared breaking ties, never the highest version. Gradle defaults to highest-version-wins across the whole graph, so Gradle intuition applied to a POM leads to ineffective fixes on deeper transitives.

Why does NoClassDefFoundError appear at runtime when the build compiled cleanly?▼

The dependency is likely declared compileOnly, provided, or optional while being reached at runtime through reflection, generated bytecode, or a ServiceLoader. Check the runtimeClasspath configuration or dependency:list -DincludeScope=runtime for the missing coordinate.

Does a Gradle version catalog pin dependency versions?▼

No. A version catalog constrains declared requests only, and conflict resolution can still select a higher transitive version silently. Only a committed gradle.lockfile created with --write-locks pins resolution.

How do I safely review a Dependabot or Renovate version bump?▼

Resolve the candidate coordinate against the real repository first, then capture dependencyInsight or dependency:tree -Dverbose on both sides of the change and diff them. Regenerate lockfiles and verification metadata, and review the verification-metadata.xml diff rather than trusting the regenerated file.

When should I not use enforcedPlatform or strictly in Gradle?▼

Avoid enforcedPlatform() and strictly(...) in any module published or consumed as a library, because the override is transitive and beats a consumer's own explicit version. They are acceptable in leaf applications, CLIs, and test configurations.