This message was deleted.

gradleApi()

is treated specially, I believe (ditto other internal dependencies like

gradleTestKit()

and

localGroovy()

)

I just got into an issue because it was pulled transitively from another module

api()

is the right thing if you're publicly exposing anything based on that dependency's types, which I think a plugin is expected to do?

Mmmm fair point. Although in that case, removing it from the POM sounds counterintuitive...

I guess it's just because what Gradle wants can't be expressed in POM, but IDK why it doesn't seem to have some representation in GMM either (unless I'm missing it)

nah, gradle api is implicit dependency, it isn't present in apiElements not runtimeElements in module metadata

redistributed API aside, doesn't that mean a library using a plugin as a dependency would have different behavior depending on whether it's a source or binary dependency? there's probably not that many cases where you're doing that aside from building another plugin, but it still seems… odd

I'm not sure, never used source deps (if you mean this https://blog.gradle.org/introducing-source-dependencies) In case of the second plugin depending on the first one I have

gradleApi()

in both (implicitly via `kotlin-dsl`/`java-gradle-plugin` usually), so for more or less standard workflow you wouldn't see a difference

I meant depending on a sibling project within the same build (where the outgoing variant seems to contain

gradleApi()

) versus depending on a binary artifact (where the GMM doesn't have any remnant of

gradleApi()

)

I'm doing something like this:

:module1

plugins {
  id("java-gradle-plugin")
}

:module2

val testConfig = configurations.create("testConfig")
dependencies {
  add("testConfig", project(":module1"))
}
testConfig.files.forEach { println(it.name) }

And I'm getting this in the output:

/Users/mbonnin/.gradle/caches/7.3.1/generated-gradle-jars/gradle-api-7.3.1.jar

They are handled in some special way (gradleApi, gradleKotlinDsl, localGroovy and gradleTestKit use special

ClassPathNotation

).

gradleApi

is added to

api

configuration by

java-gradle-plugin

unconditionally and should be visible to the projects in the same build. I don't see where is it excluded from gmm/pom though,

pluginMaven

publication just use

publication.from(components["java"])

internally.

I don't see where is it excluded from gmm/pom though

Just made a test and it's not in the

"dependencies"

section of the module file🤷

I'm not sure if gradleApi is exposed in the case of included build

Check this lines how it could be removed

This change was actually done once but reverted shortly after: • https://github.com/gradle/gradle/pull/14240 (make it compileOnlyApi) • https://github.com/gradle/gradle/pull/14374 (turn that back) I don’t fully remember why it was changed back. There were conversations with other folks and unfortunately nothing was documented in the PRs. I think the argument was that conceptually the API is needed at runtime. So this is not really what compileOnly stands for. So conceptually this would be more like what providedCompile is in the war plugin (I think). But (for me) it’s a question of perspective and I think it could be made compileOnlyApi.

Oooh nice find, thanks for all the context 🤗 !