[GRADLE-3120] maven-publish doesn't take resolutionStrategy into account Created: 02/Jul/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 7


 Description   

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?

 Comments   
Comment by Gradle Forums [ 02/Jul/14 ]

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.

Comment by Gradle Forums [ 02/Jul/14 ]

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.

Comment by SImon Hartley [ 08/Sep/15 ]

The spring-boot-gradle-plugin uses a resolutionStrategy to manage external spring boot dependencies.

Because the resolutionStrategy doesn't run during publishing you cannot use this feature of the spring-boot-gradle-plugin if you want to publish your project, which means you have to fall back on explicit version declarations.

Comment by Vinicius Isola [ 24/Mar/16 ]

Is there any work around for this? I'm migrating a Maven build to Gradle but we keep our artifacts in a Nexus repository and load versions from a central base pom. I can't explicitly set the versions in Gradle files.

I'm loading and parsing the dependencies from the base pom and adding them to `resolutionStrategy` dynamically but I need them to be published in my POMs so that other Maven builds can use my builds, otherwise I keep getting errors like the following:

Caused by: org.gradle.api.internal.artifacts.ivyservice.ivyresolve.parser.UnresolvedDependencyVersionException: Unable to resolve version for dependency 'com.google.guava:guava:jar'

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:40:32 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.