# Resolving Specific Artifacts

version 9.7.0-rc-3

When resolving a module from a Maven or Ivy repository, Gradle looks for metadata (e.g., `.module`, `pom.xml`, `ivy.xml`) and a default artifact file (typically a JAR). If neither is found, the resolution fails.

In some cases, you may want to override this behavior and request only a specific artifact from a module:

- The module provides only a non-standard artifact (e.g., a ZIP file) with no metadata.

- The module publishes multiple artifacts, and you only want one of them.

- You want to avoid resolving transitive dependencies declared in metadata.

Gradle supports this use case with artifact-only notation, where you append an `@<extension>` to the dependency coordinates. This instructs Gradle to resolve only the artifact with that file extension and skip metadata-based resolution entirely.

| The `@<extension>` only works for module dependencies.

For example, suppose you’re building a web application and want to fetch a JavaScript library directly from a repository rather than checking it into version control. The Google Hosted Libraries platform distributes many open-source JavaScript libraries this way.

To download the `.js` artifact directly, use the `@js` syntax:

build.gradle

    repositories {
        ivy {
            url = 'https://ajax.googleapis.com/ajax/libs'
            patternLayout {
                artifact '[organization]/[revision]/[module].[ext]'
            }
            metadataSources {
                artifact()
            }
        }
    }

    configurations {
        js
    }

    dependencies {
        js 'jquery:jquery:3.2.1@js'
    }

build.gradle.kts

    repositories {
        ivy {
            url = uri("https://ajax.googleapis.com/ajax/libs")
            patternLayout {
                artifact("[organization]/[revision]/[module].[ext]")
            }
            metadataSources {
                artifact()
            }
        }
    }

    configurations {
        create("js")
    }

    dependencies {
        "js"("jquery:jquery:3.2.1@js")
    }

Some modules publish multiple "flavors" of the same artifact—for example, compiled classes, source code, or Javadocs. In JavaScript, a library may publish both an uncompressed and a minified version. These variants are often distinguished using a classifier, a common concept in Maven and Ivy.

To request an artifact with a specific classifier, include it in the dependency notation. The following example resolves the minified version of a JQuery library using the classifier `min`:

build.gradle

    repositories {
        ivy {
            url = 'https://ajax.googleapis.com/ajax/libs'
            patternLayout {
                artifact '[organization]/[revision]/[module](.[classifier]).[ext]'
            }
            metadataSources {
                artifact()
            }
        }
    }

    configurations {
        js
    }

    dependencies {
        js 'jquery:jquery:3.2.1:min@js'
    }

build.gradle.kts

    repositories {
        ivy {
            url = uri("https://ajax.googleapis.com/ajax/libs")
            patternLayout {
                artifact("[organization]/[revision]/[module](.[classifier]).[ext]")
            }
            metadataSources {
                artifact()
            }
        }
    }

    configurations {
        create("js")
    }

    dependencies {
        "js"("jquery:jquery:3.2.1:min@js")
    }

Using `@extension` bypasses metadata-based resolution. Gradle will not attempt to download or interpret module metadata (e.g., `.module`, `pom.xml`, `ivy.xml`), and will treat the coordinates as a direct request for a single artifact. As a result, variant-aware resolution, capabilities, and transitive dependencies are all bypassed. If no metadata is available and the requested artifact cannot be found, the build may fail. In such cases, you may need to provide module metadata using component metadata rules.