We have a Gradle build that includes a buildSrc
with some custom plugins. Those plugins apply yet other plugins. For example, our plugin applies com.android.tools.build:gradle
. For annotation processing that library needs to be on Gradle's classpath during compilation. So, putting this in our main build.gradle
works:
buildscript { repositories { google() } dependencies { classpath "com.android.tools.build:gradle:$gToolsVersion" } }
However, that means that for a user to apply this plugin they must (1) apply our plugin and (2) add that buildscript
boilerplate. It seems like that shouldn't be necessary. We can also add a project.buildscript
block inside our plugin but that too seems unnecessary and, due to this bug is problematic: https://developer.android.com/studio/build/gradle-plugin-3-0-0.html?utm_source=android-studio#known_issues.
I added the com.android.tools.build:gradle
dependency to buildSrc/build.gradle
as a runtime
dependency. It seems like that should work: I thought that tells Gradle that in order to run my plugin that library (and its dependencies) need to be on the classpath. However, gradle buildEnvironment
(and the fact that our build fails) makes it clear that's not the case.
So, questions:
- What's the difference between a
runtime
dependency specified inbuildSrc/build.gradle
and aclasspath
dependency specified in abuildscript
block in a regular build.gradle? - How can I arrange things so that users can apply the plugin from
buildSrc
and not have to also add thebuildscript
block to theirbuild.gradle
?
0 comments:
Post a Comment