Maven-publish doesn't take resolutionStrategy into account

Old Forum Archive
1

I’m not sure if this is a known issue, but I want to be clear. It appears that MavenPublication.from reads the dependencies directly, instead of the resolved configuration, meaning that any eachDependency lines are ignored when publishing.

Here’s an example:

apply plugin: 'java'
apply plugin: 'maven-publish'
  group = 'test'
version = '1.0'
  repositories { jcenter() }
  publishing {
publications {
    mavenJava(MavenPublication) {
        from components.java
    }
}
}
   dependencies {
   compile 'com.google.guava:guava:16.0'
}
  configurations.all {
    resolutionStrategy {
        eachDependency { details ->
            if (details.requested.name == 'guava') {
                details.useTarget group: details.requested.group, name: 'guava-tests-jdk5', version: details.requested.version
            }
        }
    }
}

run “gradlew publishToMavenLocal” and look at ~/.m2/repository/test/resolution-strategy-publish/1.0/resolution-strategy-publish-1.0.pom. It has guava instead of guava-tests-jdk5, even though that the resolved configuration shows. E.g.

<dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>16.0</version>
      <scope>runtime</scope>
</dependency>

When the gradle dependencies shows

runtime - Runtime classpath for source set 'main'.
\--- com.google.guava:guava:16.0 -> com.google.guava:guava-tests-jdk5:16.0
     \--- com.google.code.findbugs:jsr305:1.3.9

I tried a few versions of gradle, including 2.0-rc-2 and it seems to alway be there. Can someone confirm that this is true?

2

Yes this would be right. The ‘resolutionStrategy’ is used only when resolving dependencies. No resolution is necessarily performed in order to generate the pom/ivy file for publishing. Since the dependencies included in publishing are normally declared directly in the build script, this isn’t usually an issue.

3

I came to same conclusion, this is only relevant for when you use resolutionStrategy for own dependencies. In which case, you could have just fixed your dependency.

Though there are teams that use a global mechanism to set dependencies for many projects, but a single project might know/want a slightly different dependency. Which means that it’s hard to make a small modification to a dependency, since you’re not directly in control of it. So, it would be nice to have maven-publish/ivy-publish take the resolved configuration into account. Can you file a JIRA?

Our plan is to do a check before pom/ivy generation that looks for discrepancies between the configuration and the resolved configuration, and throw an error if found.

4

Done: GRADLE-3120. I’m not sure we’ll want to simply switch to using the resolved versions, but having the resolved configuration available when publishing would make sense for publishing rev & revconstraint in ivy, and probably a lot of other use cases as well.