You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is only a problem when using Kotlin build files. Any configuration which comes from a binary plugin will have DSL accessor functions created for it.
For example, this means that any project with a Java or Kotlin plugin will have functions like implementation(/* ... */) or api(/* ... */).
If a project uses a convention plugin from a precompiled binary (buildSrc or an included build), and that precompiled plugin includes a configuration, then that configuration will also have functions.
However, if a configuration (or source set) is declared locally or in a script, then there won't be a function for it. Instead, the Kotlin DSL has String extension functions for adding dependencies. For instance, "internalReleaseApi"(/* ... */).
Given a build file like this:
plugins { /* ... */ }
android {
buildTypes {
// creates a new SourceSet, which in turn creates configurations like 'internalReleaseApi'
register("internalRelease").configure { /* ... */ }
}
sourceSets.getByName("internalRelease").java.srcDirs("src/debug/java", "src/main/java")
}
dependencies {
"internalReleaseApi"(project(path =":lib2"))
}
Assume there's also an inherited dependency, :lib1, which is currently being provided by :lib2.
If :lib1 should be an api dependency, then auto-correct will correctly add it as "internalReleaseApi"(project(path = ":lib1")). This is because it's copying the existing declaration and then doing a replace.
If :lib1 doesn't need to be an api dependency, then it will be added incorrectly as internalReleaseImplementation(project(path = ":lib1")). That function does not exist.
There doesn't seem to be a perfect solution to this which doesn't require a lot more parsing.
A decent solution would be checking whether the config is one of those provided by the KGP/AGP/JGP. If it is, then add it as a function. If it isn't standard but there's an existing declaration with the same config name, then obviously just copy the existing. This should catch any configs which are added as part of custom plugins. Finally, if it isn't standard and there are no other examples, then add it using quotes. It might be unnecessarily ugly that way, but it'll build.
The text was updated successfully, but these errors were encountered:
This is only a problem when using Kotlin build files. Any configuration which comes from a binary plugin will have DSL accessor functions created for it.
For example, this means that any project with a Java or Kotlin plugin will have functions like
implementation(/* ... */)
orapi(/* ... */)
.If a project uses a convention plugin from a precompiled binary (
buildSrc
or an included build), and that precompiled plugin includes a configuration, then that configuration will also have functions.However, if a configuration (or source set) is declared locally or in a script, then there won't be a function for it. Instead, the Kotlin DSL has String extension functions for adding dependencies. For instance,
"internalReleaseApi"(/* ... */)
.Given a build file like this:
Assume there's also an inherited dependency,
:lib1
, which is currently being provided by:lib2
.If
:lib1
should be anapi
dependency, then auto-correct will correctly add it as"internalReleaseApi"(project(path = ":lib1"))
. This is because it's copying the existing declaration and then doing a replace.If
:lib1
doesn't need to be anapi
dependency, then it will be added incorrectly asinternalReleaseImplementation(project(path = ":lib1"))
. That function does not exist.There doesn't seem to be a perfect solution to this which doesn't require a lot more parsing.
A decent solution would be checking whether the config is one of those provided by the KGP/AGP/JGP. If it is, then add it as a function. If it isn't standard but there's an existing declaration with the same config name, then obviously just copy the existing. This should catch any configs which are added as part of custom plugins. Finally, if it isn't standard and there are no other examples, then add it using quotes. It might be unnecessarily ugly that way, but it'll build.
The text was updated successfully, but these errors were encountered: