Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A dependency in both api & implementation configurations should be considered api #257

Closed
Mahoney opened this issue Aug 27, 2020 · 4 comments
Labels
bug Something isn't working
Milestone

Comments

@Mahoney
Copy link

Mahoney commented Aug 27, 2020

Build scan link
https://gradle.com/s/t57ilkpm4gplg

Plugin version
0.56.0

Gradle version
6.6

Android Gradle Plugin (AGP) version
N/A

Describe the bug
If a dependency is explicitly declared in both the implementation and api configurations the plugin considers it to be an implementation dependency, when it should be considered an api dependency.

This happens if you declare it as an implementation dependency for all subprojects, then in a subproject upgrade it to an api dependency, resulting in warnings from the plugin that it ought to be api when it isn't.

(It also happens if you declare it as an api dependency for all subprojects, then try to downgrade it to implementation in a subproject for which it does not need to be api - no warning is shown, so the plugin thinks it is implementation. It may be correct, but I suspect it's actually in both, and the plugin is wrongly ignoring its presence in API.)

To Reproduce
Create a parent build.gradle.kts as so:

subprojects {
  dependencies {
      val implementation by configurations
      implementation(kotlin("stdlib"))
  }
}

Build a subproject as so:

dependencies {
  api(kotlin("stdlib"))
}

Make the subproject export a Kotlin class in its public api - a suspend function seems to do it. Or don't use kotlin, use some other lib!

Run ./gradlew buildHealth.

Observe warnings that kotlin-stdlib is implementation but ought to be api.

Expected behavior
The dependency analysis is happy, considering the sub project to be correct in declaring the dependency as api.

@autonomousapps
Copy link
Owner

I was able to reproduce this by adding this task to one of my projects:

tasks.register("impl") {
    println 'implementation dependencies:'
    configurations.implementation.dependencies.forEach { dep ->
        if (dep instanceof org.gradle.api.artifacts.ModuleDependency) {
            println "- ${dep.group}:${dep.name}"
        }
    }
    println 'api dependencies:'
    configurations.api.dependencies.forEach { dep ->
        if (dep instanceof org.gradle.api.artifacts.ModuleDependency) {
            println "- ${dep.group}:${dep.name}"
        }
    }
}

Executing it prints

implementation dependencies:
- org.jetbrains.kotlin:kotlin-stdlib-jdk8
api dependencies:
- org.jetbrains.kotlin:kotlin-stdlib-jdk8

(With a similar setup to what you've described.)

So, this looks like a bug where I stop when I find the first match, rather than looking at all configurations.

@autonomousapps autonomousapps added the bug Something isn't working label Aug 27, 2020
@autonomousapps autonomousapps added this to the 1.0 milestone Aug 27, 2020
@autonomousapps
Copy link
Owner

I'm not entirely sure of the best way to resolve this, since I don't yet understand the implications of declaring a dependency on multiple configurations. I've asked about this in the gradle slack.

As a first pass, I have some code that detects this and emits a warning, since it is probably unintentional. Here's what the warning looks like right now:

Dependency org.jetbrains.kotlin:kotlin-stdlib-jdk8 has been declared multiple times: [api, implementation]

@autonomousapps
Copy link
Owner

I have gotten a response, and the summary is that, if you have a dependency on both api and implementation, it is functionally api. With this, I can fix the plugin's behavior to be aware of that.

@autonomousapps
Copy link
Owner

Closing this as resolved. It will be available in 0.58.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants