Comprehensive Rules for managing dependencies in large-scale Java projects using Maven or Gradle, with a focus on reproducible builds, security, and maintainability.
Managing dependencies in large Java projects shouldn't feel like defusing a bomb every time you run a build. You've been there—production deployments failing because of version conflicts, security vulnerabilities slipping through, or worse, spending hours debugging why your local build works but CI doesn't.
Here's what's actually happening in your large Java projects:
Version Drift Hell: Teams pin different versions of the same library across modules, leading to runtime ClassNotFoundException or NoSuchMethodError that only surface in production.
Security Blind Spots: You're pulling in 200+ transitive dependencies, and you have no idea which ones contain CVEs or what licenses they're under until it's audit time.
Build Reproducibility Nightmare: "Works on my machine" isn't just a meme—it's your daily reality when SNAPSHOT versions get resolved differently across environments.
CI/CD Bottlenecks: Builds fail randomly because someone added a dependency that conflicts with existing ones, or worse, downloads fail because you're hitting public repositories directly.
These Cursor Rules turn Cursor into your dependency management command center, automatically generating the build configurations, security checks, and documentation patterns that enterprise Java projects actually need.
Instead of manually researching Maven configurations or Gradle DSL syntax, you get:
Cut Dependency Research Time by 80%: Instead of spending hours researching proper Maven <dependencyManagement> patterns or Gradle Version Catalogs, get production-ready configurations instantly.
Eliminate Version Conflict Debugging: Automatically generates dependency convergence rules and conflict resolution strategies that catch issues at build time, not runtime.
Reduce Security Incident Response: Built-in OWASP integration and license scanning patterns mean you catch vulnerabilities before they reach production.
Accelerate Onboarding: New team members get consistent, documented dependency patterns instead of learning through trial and error.
<!-- Developer manually adds dependency -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.15.2</version> <!-- Different version than other modules -->
</dependency>
Hours later: ClassCastException in production because Module A uses Jackson 2.15.2 but Module B uses 2.14.1.
With these rules, when you type "add jackson dependency," Cursor generates:
<!-- Parent POM automatically configured -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-bom</artifactId>
<version>2.17.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Plus the module-specific dependency without version conflicts, OWASP scan configuration, and proper documentation.
Request "centralize Spring Boot versions" and get:
# libs.versions.toml
[versions]
spring-boot = "3.2.1"
jackson = "2.17.0"
[libraries]
spring-boot-starter-web = { group = "org.springframework.boot", name = "spring-boot-starter-web", version.ref = "spring-boot" }
jackson-core = { group = "com.fasterxml.jackson.core", name = "jackson-core", version.ref = "jackson" }
[bundles]
spring-web = ["spring-boot-starter-web", "jackson-core"]
Copy the Cursor Rules into your .cursorrules file in your project root.
Open your main pom.xml or build.gradle and describe your current setup:
Ask for specific patterns:
Request: "Add OWASP dependency-check with CVSS 7.0 threshold"
Get production-ready configuration:
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>8.4.2</version>
<configuration>
<failBuildOnCVSS>7.0</failBuildOnCVSS>
<suppressionFile>owasp-suppressions.xml</suppressionFile>
</configuration>
</plugin>
Ask for "Dependabot configuration for Java dependencies" and get:
version: 2
updates:
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "weekly"
reviewers:
- "platform-team"
labels:
- "chore(deps)"
Week 1: Your build times become predictable because all dependencies resolve consistently across environments.
Month 1: Security audits become routine instead of emergency fire drills—you catch CVEs before they reach production.
Quarter 1: New services spin up in hours instead of days because you have proven dependency patterns and configurations.
Real Metrics from Teams Using These Patterns:
// Automatically generates proper module-info.java
module com.company.userservice {
requires spring.boot.starter.web;
requires spring.boot.starter.data.jpa;
exports com.company.userservice.api;
// Internal packages remain encapsulated
}
<!-- Nexus proxy configuration with security -->
<repositories>
<repository>
<id>nexus-central</id>
<url>https://nexus.company.com/repository/maven-public/</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
<plugin>
<groupId>org.cyclonedx</groupId>
<artifactId>cyclonedx-maven-plugin</artifactId>
<version>2.7.9</version>
<executions>
<execution>
<goals>
<goal>makeBom</goal>
</goals>
</execution>
</executions>
</plugin>
These aren't just configuration snippets—they're complete, production-tested patterns that handle edge cases, security requirements, and enterprise constraints you haven't even thought of yet.
Your Java projects deserve dependency management that scales with your team, not against it. Stop fighting build failures and start building features.
You are an expert in Java (8–21), Maven, Gradle (Groovy & Kotlin DSL), Spring, Dagger, Nexus Repository, Artifactory, Dependabot, Renovate, SonarQube, OWASP Dependency-Check, and the Java Platform Module System (JPMS).
Key Principles
- Treat dependencies as first-class code assets: review, test, version-control, and document them.
- Prefer a smallest-set strategy: include only what you use; audit and remove unused transitive libraries.
- Reproducible builds are non-negotiable: pin exact versions and lock transitive graphs.
- Centralize version declarations (parent POM, BOM, or Gradle Version Catalog) to avoid drifts.
- Automate insight & updates with CI bots (Dependabot/Renovate) but gate them behind CI, static analysis, and security scans.
- Never download directly from the public Internet during CI/CD; proxy through an internal repository manager.
- Security is part of dependency management: verify signatures, hashes, SBOMs, and CVE reports.
Java
- Adopt JPMS (`module-info.java`) for new services; export only public APIs, require dependencies explicitly.
- Organize large code bases into logical multi-module builds (Maven/Gradle) rather than oversized packages.
- Use semantic versioning for internal artifacts: MAJOR = breaking API, MINOR = feature, PATCH = fix.
- In Maven, place shared versions inside `<dependencyManagement>` of a parent POM or import a Spring/Quarkus-style BOM.
- In Gradle, use Version Catalogs (`libs.versions.toml`) or `java-platform` modules to lock versions.
- Scope wisely:
• Maven: `compile` (default) only when needed at both compile & runtime. Use `runtimeOnly`, `provided`, `test`, `optional`.
• Gradle: `api`, `implementation`, `runtimeOnly`, `testImplementation`, `annotationProcessor`.
- Keep import statements explicit; avoid wildcard imports to clarify which packages are actually used.
Error Handling and Validation
- Detect version conflicts early: Maven’s `mvn dependency:tree -Dverbose` or Gradle’s `--scan` produce actionable graphs.
- Resolve clashes by forcing a single version with `dependencyManagement`, `dependency constraints`, or `strictly` clauses.
- Fail builds on:
• Unresolved or changing `SNAPSHOT` dependencies in release branches.
• CVEs above a configurable severity threshold (OWASP Dependency-Check, SonarQube plugins).
- Use early exits in helper scripts/plugins if a dependency graph violates company policy (e.g., GPL-licensed transitive lib).
Maven
- Parent POM structure:
```xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-bom</artifactId>
<version>2.17.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
```
- Prefer BOMs over individual version pins when a vendor supplies a coherent set (Spring Boot, Jakarta EE).
- Use the `maven-enforcer-plugin`:
• Ban duplicate classes (`BanDuplicateClasses` rule).
• Require stable versions (`requireReleaseDeps`).
• Enforce upper-bound dependency convergence.
Gradle
- Kotlin DSL preferred for new builds (`build.gradle.kts`).
- Centralize versions:
```toml
# libs.versions.toml
[libraries]
jackson-core = { group = "com.fasterxml.jackson.core", name = "jackson-core", version.ref = "jackson" }
[versions]
jackson = "2.17.0"
```
- Enable dependency locking: `gradle --write-locks` and commit `gradle.lockfile` to VCS.
- Activate "fail fast" on updates: `dependencyUpdates` task + `rejectVersionIf { isNonStable(candidate.version) }`.
Repository Managers (Nexus / Artifactory)
- Mirror `central`, `jcenter`, and internal releases; disable direct downloads in corporate firewalls.
- Enforce checksum validation and GPG signature verification.
- Retain immutable artifacts; delete only via scheduled cleanup policies, never overwrite versions.
Automation & CI
- Integrate Dependabot/Renovate via PRs with labels `chore(deps)`; auto-merge only patch updates that pass the full test suite.
- Run `mvn clean verify` or `./gradlew build --scan` for every PR; block merge on dependency convergence or security scan failures.
- Generate SBOMs (`cyclonedx-maven-plugin`, `cyclonedx-gradle-plugin`) and publish as build artifacts.
Testing
- Use contract tests to detect behavioral changes in upgraded libraries (Mockito + Testcontainers, Spring Cloud Contract).
- Snapshot the classpath for critical services and diff after upgrades to detect binary incompatibilities.
Performance
- Prefer shaded fat JARs only for serverless or CLI tools; otherwise use layered images to leverage Docker cache.
- Remove reflection-heavy libraries where possible; prefer annotation processors (MapStruct, Dagger) for compile-time wiring.
Security
- Run OWASP Dependency-Check (or SonarQube’s dependency scanning) on every build; treat CVSS ≥ 7.0 as build-breaking.
- Verify PGP signatures for new third-party artifacts; reject unsigned corporate deployments.
- Maintain an allow-list of approved licenses; fail on GPL, CC-BY-SA unless explicitly exempted.
Documentation
- Publish an architectural decision record (ADR) when adding or upgrading a major dependency.
- Provide a CHANGELOG entry summarizing risk, mitigation steps, and rollback strategy.
Common Pitfalls
- Relying on transitive versions: always declare direct dependencies explicitly to keep control.
- Mixing `SNAPSHOT` and release repositories causing implicit version overrides.
- Ignoring module boundaries; avoid `requires transitive` in JPMS unless absolutely required.
Quick Checklist (PR Template)
- [ ] New dependency added to central BOM/version catalog.
- [ ] License and security scan passed.
- [ ] Duplicate/unused dependency removed if superseded.
- [ ] Integration tests green on CI across Java 11 & 17 (or company LTS versions).