As we have to apply this code in all projects, we wanted to put the buildscript block into a gradle-file (lets call it setupPlugins.gradle) and include it with apply from. But this wont work because bevor a plugins block you can’t have a anything else than a buildscript block.
I don’t want to apply sonarcube at all projects which use our plugin.
Thank you for your quick response.
Unfortunately, in repository.gradle we are setting some project extra properties (like nexusGradlePluginsUrl) and using this approach results now in
Could not get unknown property ‘project’ for object of type org.gradle.api.internal.initialization.DefaultScriptHandler.
Although, I understand the problem (kind of ) I don’t know how to solve it.
I can’t get this to work in 5.6.1. I tried exactly as noted above (“apply from: …” within the “buildscript {…}” block with one exception - I did not use the URLs in “apply from: …” but a file path that is in root project’s subfolder (not a subproject).
Tried:
relative and absolute paths, tried rootProject.file(…)
with “project.buildscript {…}” in “bootstratp.gradle” as well as just “buildscript {…}” (no “project.”)
How to make it configurable and re-usable for all your needs.
I am distributing it in a jar. I release that jar to Maven Central.
I make it re-usable by creating a defaultCOnfig in the script. And a buildConfig in projects using it. Those are merged, in the script to create an effective config.
My projects may have build.gradle looking something like this:
Actually that code looks a bit anti-pattern.
Whenever you use ext you should think twice about it as usually avoid it in favor of a proper extensions that also gives you type-safety and if added in a plugin that is applied using plugins block in Kotlin DSL also gives you type-safe accessors for convenient usage.
So I’d recommend you make your code a proper plugin (can be a precompiled script plugin) and add a proper extension in it.