Gradle plugin for JVM projects written in Java, Kotlin, Groovy, or Scala; and Android projects written in Java or Kotlin. Provides advice for managing dependencies and other applied plugins
Apache License 2.0
1.82k
stars
120
forks
source link
Improve usability in pre-compiled scrip plugins by merging DependencyAnalysisExtension and DependencyAnalysisSubExtension #1267
This is, because the type of dependencyAnalysis { ... } depends on whether you use it in a root project (DependencyAnalysisExtension) or a subproject (DependencyAnalysisSubExtension). When a pre-compiled script plugin is compiled, the configuration code is executed out of context of a real project. The compilation uses a kind of artificial project for this. In this phase, DAGP always thinks that it is in a root project. This can have the following effects:
The script does not compile, because you attempt to use a construct only available in DependencyAnalysisSubExtension
If compilation is successful, you get a ClassCast exception inside the code generated by Gradle when the plugin is used inside a subproject (which may look like a bug in the plugin to users).
Describe the solution you'd like
Because the pre-compiled script plugin never knows the context it will be applied in later, the only solution I see for this is to not register different types as dependencyAnalysis depending on the context.
I think the functionality of both types could be merged into one. The details would have to be sorted out for the constructs that are currently not available in one of the contexts.
For instance, there will then always be a all {} and project(...) {} selector, even if you are in a subproject. These could be no-ops, or can apply things to subprojects-of-a-subproject. Or/and give an error if there are no subprojects.
Describe alternatives you've considered
You can use configure<TypeOfExtension> instead of dependencyAnalysis when you know in which context your pre-compiled script plugin will be used and choose the correct type there:
This is a usability improvement for certain setups. Maybe it also makes the configuration DSL more clear in general, as it can be confusing that the same notation allows for different things in different contexts (but I don't know if that is really the case here). The "workaround" is working well. This does not need to be handled with high priority.
Is your feature request related to a problem? Please describe.
If you define a pre-compiled script plugin, the below does not work:
This is, because the type of
dependencyAnalysis { ... }
depends on whether you use it in a root project (DependencyAnalysisExtension
) or a subproject (DependencyAnalysisSubExtension
). When a pre-compiled script plugin is compiled, the configuration code is executed out of context of a real project. The compilation uses a kind of artificial project for this. In this phase, DAGP always thinks that it is in a root project. This can have the following effects:DependencyAnalysisSubExtension
Describe the solution you'd like
Because the pre-compiled script plugin never knows the context it will be applied in later, the only solution I see for this is to not register different types as
dependencyAnalysis
depending on the context. I think the functionality of both types could be merged into one. The details would have to be sorted out for the constructs that are currently not available in one of the contexts. For instance, there will then always be aall {}
andproject(...) {}
selector, even if you are in a subproject. These could be no-ops, or can apply things to subprojects-of-a-subproject. Or/and give an error if there are no subprojects.Describe alternatives you've considered
You can use
configure<TypeOfExtension>
instead ofdependencyAnalysis
when you know in which context your pre-compiled script plugin will be used and choose the correct type there:Additional context
The example used in a project: https://github.com/jjohannes/gradle-project-setup-howto/blob/main/gradle/plugins/src/main/kotlin/org.example.gradle.check.dependencies.gradle.kts
This is a usability improvement for certain setups. Maybe it also makes the configuration DSL more clear in general, as it can be confusing that the same notation allows for different things in different contexts (but I don't know if that is really the case here). The "workaround" is working well. This does not need to be handled with high priority.