## Problem to solve Based on the completed spike validation, we need to implement Gradle dependency auto-resolution for the new Dependency Scanning Job Orchestration architecture. The spike confirmed that a gradlew-first approach with Java 17 can achieve 50% project coverage (matching current Gemnasium analyzer performance) while simplifying our maintenance overhead. ## Proposal Implement a Gradle dependency resolution job that uses native `gradle dependencies` command with a simplified runtime environment, replacing the current multi-version Gemnasium approach. ### Architecture Overview **Runtime Environment:** * Base image: Java 17 + Gradle 8 (single version) * Strategy: gradlew-first with system Gradle fallback * Dependencies: git, curl for gradlew downloads **Resolution Strategy:** 1. **Primary**: Execute `./gradlew dependencies` if wrapper exists 2. **Fallback**: Use bundled `gradle dependencies` for projects without wrapper 3. **Combined coverage**: \~65% success rate (union of both approaches) ### Success Criteria * [ ] Achieve 50% project success rate (parity with current Gemnasium) * [ ] Handle both single-module and multi-module projects * [ ] Support air-gapped environments * [ ] Provide clear error messages for unsupported project configurations ### Technical Constraints **Known Limitations:** * 50% success rate ceiling due to Gradle ecosystem fragmentation * Gradle \< 7.0 incompatible with Java 17 (15% of projects) * Multi-module projects may require per-module resolution (20% of projects) * Project maintenance issues affect 15% of projects **Air-gapped Support:** * Requires pre-populated Gradle distribution cache * Needs access to dependency repositories or mirrors * gradlew downloads must be available locally ### Related Work * Spike validation: [#586914](https://gitlab.com/gitlab-org/gitlab/-/issues/586914) * Maven implementation: [#584580](https://gitlab.com/gitlab-org/gitlab/-/work_items/584580)