https://gradle.com/ logo
Join Slack
Powered by
Is it possible to centralize buildscript repositor...
# community-support
m
Is it possible to centralize buildscript repositories in 
settings.gradle.kts
?
Copy code
// build.gradle.kts
buildscript {
    dependencies {
        // ...
    }
    // Can I move this to settings.gradle.kts?
    repositories {
        mavenCentral()
    }
}
This is possible for 
plugins{}
and regular dependencies but I haven't found a way for 
buildscript {}
. Is there a way?
v
Best is to remove the need to have 
buildscript
blocks at all. 🙂 Besides that, I'm not sure whether the plugin repositories are also used for that? If not, it might be possible with 
gradle.beforeProject { ... }
.
t
pluginManagement.repositories
are used for buildscripts yes (I have to use 
buildscript
to add the JDBC driver when using the jOOQ-gradle-plugin edit: FlywayDB gradle plugin, and declare the repository in the settings script)
m
Really? I swear that wasn't working
I get this:
Copy code
A problem occurred configuring root project 'tmp'.
> Could not resolve all artifacts for configuration ':classpath'.
   > Cannot resolve external dependency org.jetbrains.kotlin:kotlin-gradle-plugin:2.0.20 because no repositories are defined.
     Required by:
         root project :
settings.gradle.kts:
Copy code
pluginManagement {
  repositories {
    mavenCentral()
  }
}
build.gradle.kts
Copy code
buildscript {
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:2.0.20")
    }
}
t
Hmm, strange actually… I've had this 
buildscript
with 
dependencies
and no single 
repositories
since Gradle 5.0 in the project I'm looking at (so no 
pluginManagement
at the time! settings script only declared subprojects and the root project's name; that was nearly 6 years ago); I don't even understand how/why it works 🤣 The project has since been updated to Gradle 8.4 and repository declarations centralized in the settings script (and at some point 
pluginManagement.repositories
was added to add 
mavenCentral()
in front of 
gradlePluginPortal()
to bypass JCenter) and this has continued to work throughout without any 
buildscript.repositories
ever added 🤷 Maybe it works because the build script also includes a 
plugins {}
block then?
🏆 1
v
Actually for that dependency as I mentioned you shouldn't use the buildscript block at all. Just use a plugins block with 
apply false
For things like the jdbc driver you can use the buildscript block, or you could add it as 
buildSrc
dependency, or you could have an included build with a no-op plugin that has it as dependency and then apply that.
m
> Maybe it works because the build script also includes a 
plugins {}
block then? OMG this is it!
til 1
What we need is a “no-op” plugin just to enable 
buildscripts
😂
v
lifecycle-base
? Not exactly no-op, but the bottom-most built-in one.
Or don't use 
buildscript
block 🙂
m
I’ve been down the 
plugins {}
stuff, now I like 
buildscript {}
better
Mostly because when I inevitably need to move my plugins to a 
build-logic
included build, I already have the gav for them
v
But it is discouraged, especially for plugins
m
Instead of having to convert always between id <-> gav
v
And for the gav you can easily use the marker artifact
m
I know it’s discouraged, I’ll just keep enjoying it while I can
👌 1
v
<plugin-id>:<plugin-id>.gradle.plugin:<plugin-version>
m
yea, but I can’t copy/pasta, I have to type chars 🙃
Me likes copy pasta gavs
v
Use a version catalog. Some day you can directly use the plugin entry as dependency, for now I have a simple extension function that makes them usable as dependencies 🙂
m
Can you use 
libs.plugins
in dependencies?
Copy code
dependencies {
  implementation(libs.kotlin.gradle.plugin)
}
?
v
As I said, one day you will built-in, there is an open issue. Right now it is a simple extension function that allows it.
👍 1
m
oh ok 👍
Yea, that’d work
v
What I do right now is 
implementation(plugin(libs.plugins.versions))
with the function being
Copy code
fun DependencyHandlerScope.plugin(plugin: Provider<PluginDependency>) = _plugin(plugin)
fun GradleDependencies.plugin(plugin: Provider<PluginDependency>) = _plugin(plugin)

private fun _plugin(plugin: Provider<PluginDependency>) = plugin.map {
    val version = if (it.version.requiredVersion == "embeddedKotlinVersion") embeddedKotlinVersion else it.version.requiredVersion
    "${it.pluginId}:${it.pluginId}.gradle.plugin:$version"
}
👍 1
It can be a tad simpler, I have a special case for embedded kotlin version
👍 1
This is the FR for the built-in functionality: https://github.com/gradle/gradle/issues/17963
⭐ 1
m
Starred
👌 1
Another fun one and I'll stop. If you have a simple 
build-logic
included build, this works in `build.gradle.kts`:
Copy code
buildscript {
    dependencies {
        classpath("build-logic:build-logic:2.0.20")
    }
}
But not in 
build.gradle
because Gradle doesn't know how to resolve 
kotlin-stdlib
v
I did not fully get that. Why should Gradle not know how to resolve it? As long as the repository where to resolve from is specified like always with any dependency.
And why should this be different in a Kotlin DSL build script?
Sounds like a bug for which you should knit an MCVE and report from what I got
m
> Why should Gradle not know how to resolve it? Because there's no repositories. 
build.gradle.kts
already has 
kotlin-stdlib
so (I guess), it doesn't try to resolve it. But 
build.gradle
tries and fails (because no repositories in 
buildscript {}
).
Not a huge deal. Just good "Gradle puzzlers" material
v
Hm, I see. :-/
11 Views
Open in Slack
PreviousNext
Powered by