Dependency resolution, classifiers and Maven interoperability

(Thomas Küstermann) #1

Hi Gradle experts,

We have a number of Maven and Gradle projects here and I thought it is a good idea to use mavenLocal() to consume artifacts generated by Maven (especially those under development). Now I’m confronted with an issue regarding classifier dependency resolution within Gradle.

We’ve got a library project (let’s call it sample-library) that produces two artifacts. The first one is the main artifact and the second one contains only the projects resources (src/main/resources) thus has classifier resources. Assume the local Maven repository is empty and a Maven projects demands com.acme:sample-library:0.0.10-SNAPSHOT. ~/.m2/repository now looks like this:


Afterwards in our Gradle project, we consume only the resources artifact com.acme:sample-library:0.0.10-SNAPSHOT:resources. When building the project I got the following error message:


FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration ':compile'.
> Could not find sample-library-resources.jar (com.acme:sample-library:0.0.10-SNAPSHOT).
  Searched in the following locations:

The build.gradle contains repository configuration for our corporate Nexus instance:

repositories {

    maven {
        url "$nexus/groups/company"

        credentials {
            username nexusUsername
            password nexusPassword

    maven {
        url "$nexus/groups/public"

        credentials {
            username nexusUsername
            password nexusPassword

As Nexus contains the required (classifier) artifact, I expect Gradle to download the artifact if it cannot be found in mavenLocal().

Is this a bug?

(Benjamin Muschko) #2

Your M2 local cache directory listing doesn’t look like it actually contains an artifact with the resources classifier. Is this missing or just not shown?

(Thomas Küstermann) #3

Thanks for the interest! The artifact with the resources classifier is indeed missing in the M2 local cache directory. But as the initial Maven project build has only a dependency to the main artifact (without classifier) I think that’s reasonable behavior.

(Thomas Küstermann) #4

Is it worth to file an issue?


This issue is already reported as GRADLE-3178.

(Thomas Küstermann) #6

Thanks for pointing this out daz! Is this scheduled to be fixed in a future release?


No, this fix is not currently scheduled.

If we find a repository that has metadata for a module, we assume that it contains all of the artifacts for that module. Unfortunately this is different from Maven. The best workaround is usually to remove mavenLocal from your repository list, or at the very least put it last.

(Raymond Augé) #8

This isn’t a very good solution because the local repo (.m2) typically isn’t a complete repo, i.e. you only have a subset of what’s contained in external repos. In the case of classifiers, there could be N classified artifacts for any given artifact and NO way for the caller to know how to download all those since there’s no listing mechanism in maven to identify all the classified artifacts.

A good example of this is saxon:

How is the local repo supposed to handle that?