Maven ↔ Gradle dependency converter
Paste a dependency in any of these formats and pick the one you need. The input format is detected, so there is nothing to set on the way in.
Scopes and configurations
Maven has scopes and Gradle has configurations. They line up, but not one for one — Gradle splits Maven's compile according to whether the dependency appears in your API:
| Maven scope | Gradle configuration | On the consumer's compile classpath? |
|---|---|---|
compile (default) | implementation | No |
compile | api | Yes |
provided | compileOnly | No |
runtime | runtimeOnly | No |
test | testImplementation | No |
Maven's compile maps to two things. This converter picksimplementation, which is right almost always and keeps your internal dependencies out of downstream compile classpaths. Use api only when a type from that dependency appears in your own public signatures — in a library module, getting this wrong forces consumers to add the dependency themselves.
Dependencies with no version
A dependency managed by a BOM has no <version>, and the converter keeps it that way. In Gradle the equivalent is the Spring Boot dependency management plugin or a platform:
implementation(platform("org.springframework.boot:spring-boot-dependencies:3.4.1"))
implementation("org.springframework.boot:spring-boot-starter-web")What does not carry across
${property}placeholders. Maven resolves them from<properties>, which is not part of the dependency block, so they come through as written.<optional>. Gradle has no direct equivalent; the closest is a separate feature variant.- Version ranges. Both build tools support them with different syntax and different resolution rules, so check any range by hand.
Where to find the coordinate
For Spring projects, start.spring.io generates the whole build file with managed versions, which is usually less error-prone than adding a starter by hand. This tool is for the dependency that is not in the initializr — copied from a README, an answer, or an existing Maven project you are porting.