is it possible to reach `libs` from `gradle/libs.v...

# gradle

[Mustafa Ozhan]

is it possible to reach libs from gradle/libs.versions.toml in pre-compiled scripts located in buildScr/src/main/kotlin ?

[CLOVIS]

Yes, you have to configure your included build to access it.

Here's an example with an included build in gradle/conventions , it's the same in buildSrc : https://gitlab.com/opensavvy/decouple/-/blob/110-gradle/gradle/conventions/settings.gradle.kts#L11

[Mustafa Ozhan]

I have that part actually, it makes it visible in
buildScr/build.gradle.kts that’s fine
but I want to reach it also inside
buildScr/src/main/kotlin/some.name.gradle.kts

[CLOVIS]

Ah, sorry. I don't know, then.

[Adam S]

https://github.com/gradle/gradle/issues/15383#issuecomment-779893192

[Adam S]

there’s a workaround in that issue

[Mustafa Ozhan]

Ohh great thanks a lot Adam!

[Vampire]

It's a hack-around, not a work-around. :-D

[Vampire]

And there is a proper but stringly API to access them

[Mustafa Ozhan]

Yea but works like a charm thank you 🙂

[Javier]

@Vampire it is almost an official hackaround, everyone is using it hahah

[Vampire]

Yep, glad I could help so many with it. :-)

[Mustafa Ozhan]

it looks like this hackaround is still not enough to use in plugin block right ? I confirm that I am now able to use libs in gradle file of included build but I can not use the libs inside plugins {…} block, perhaps it is not integrated yet when the plugins block is being read.
Maybe there is another hackaround for that too ? 😄

[Adam S]

the plugins block is pretty limited, intentionally

https://docs.gradle.org/current/userguide/plugins.html#sec:constrained_syntax

What are you trying to do though? I suspect there might be a better way...

[Humphrey]

I think you should use alias() in the plug-in block

[Vampire]

Your are right that it does not work and there is no other hackaround.

[Vampire]

He cannot use alias, as he cannot use the version catalog.

[Mustafa Ozhan]

Yea, I also wanted to reach [plugins] from TOML file in my build.gradle but it seems not possible,

I mean it is possible everywhere except

plugins {
   // here is not possible
}

dependencies {
   // here is possible
}

I think the reason is when the plugins block is applied the version catalogs are not integrated yet.

I wanted to keep the name of pre-compiled plugins inside TOML file and avoid statically writing

[Adam S]

yes that's true, you will have to duplicate the plugin IDs. But that's not such a big problem tbh. Either the plugin name is right, and it works, or it's wrong and Gradle will throw an error.

And because precompiled-script plugins cannot specify a version in the plugins {} block (see docs), you have to specify the plugin version in the dependencies block in buildSrc/build.gradle.kts. And you can use version catalog to do that.

[Adam S]

and you can re-use the plugin aliases in buildSrc/build.gradle.kts to specify the version of the external plugins

public fun DependencyHandlerScope.plugin(id: String, version: String): String =
    "$id:$id.gradle.plugin:$version"

public fun DependencyHandlerScope.plugin(plugin: Provider<PluginDependency>): Provider<String> =
    plugin.map { "${it.pluginId}:${it.pluginId}.gradle.plugin:${it.version}" }

https://www.linen.dev/s/gradle-community/t/10015775/one-feature-that-i-liked-about-buildsrc-is-that-i-could-defi#3c55229f-e2d0-4cd6-bff8-8137a717bd53

[Mustafa Ozhan]

Ohh according to PR in the conversatation that you send frim gradle-community, it should be possible in gradle 8.1-RC i will try with that

[Vampire]

No

[Mustafa Ozhan]

I am talkin about this PR: https://github.com/gradle/gradle/pull/23639

[Vampire]

Nothing changed in 8.1, except that you do not get an error displayed when using plugins from the version catalog in normal build scripts

[Vampire]

You still can't use them in pre-compiled script plugins

[Vampire]

As my hackaround cannot work there as it has preconditions that are not fulfilled for them

[Mustafa Ozhan]

I think they are referring for the default buildScr , and your hack-around should work for that as well

[Vampire]

Then you think wrong. My hackaround is for precompiled script plugins, no matter whether in an included build or buildSrc. That change is only about normal build script's plugins blocks.

[Vampire]

Those where you already can use them fine without my hack around, but get an ide error displayed even though it works

[Mustafa Ozhan]

Ohh right I get what you mean

[Adam S]

so, in this context, there are two types of Gradle config files.

Precompiled script plugins, e.g. buildSrc/src/main/kotlin/my-project-conventions.gradle.kts. You can't use Plugin Aliases here, and even if you could, the plugins' coordinates would have to be defined in dependencies [} in buildSrc/build.gradle.kts anyway.


And regular build.gradle.kts files

e.g.

• ./build.gradle.kts
• ./buildSrc/build.gradle.kts
• ./my-cool-subproject/build.gradle.kts.
You can use plugin aliases in these since Gradle 7.3 or something. The bugfix in 8.1 is specifically about fixing an IDE warning.

[Mustafa Ozhan]

Yea the one I want achieve is the first one you mentioned buildSrc/src/main/kotlin/my-project-conventions.gradle.kts and it seems not possible to get plugins from version catalog in plugins block, i just have to write it statically.

We wanted to share this module as git submodule between projects and then each project could have different plugin id with same name in TOML file

[Adam S]

🤯 huh

[Adam S]

sorry, I don't mean to be rude, but that sounds quite complicated. If you were able apply a plugin from versions catalog into the plugins block of a pre-compiled script plugin, what would that help you achieve? What's your end goal?

[Mustafa Ozhan]

Yes indeed it is 🙂 I am not fan of it either, it was just an idea of future structuring of the build scripts for multiple projects. It is hard to explain without a solid example but we wanted to hold all the convention scripts in shared git repo where each project could override the id of plugin in its TOML file because they are also submodule of other projects..

[Mustafa Ozhan]

But the more we dig the more complicated it gets so it is not a good idea overall, anyways thanks a lot for everyone who contributes to this conversation ❤️

[Adam S]

okay, so basically wanted a subproject to override a plugin ID as a form of 'scoping', so that plugin IDs don't clash?

[Mustafa Ozhan]

Yea clashing is a point and also as an example some project want to use

detekt = { id = "detek-commercial" }

whereas some

detekt = {id = "detek-library" }

in their TOML file but their submodules will only use

plugins { id(libs.plugins.detekt.get().pluginId) }

in gradle, so TOML file of root project will help which scripts to be used over all submodules

[Adam S]

Gotcha. I don't think such a dynamic way of loading plugins will be workable though, as you're finding out :)

[Mustafa Ozhan]

actually it could be, if we were able to use libs in plugins block, it will allow us to create only 1 PR with 1 file into main repo, instead of creating 4-5 PRs to different repositories modifying 40-50 different build.gradle files and replacing "detek-commercial" to "detek-library"

[Adam S]

so detek-commercial and detek-library are two of your own convention plugins. I presume both apply Detekt, and each have some slightly different configuration based on the final product you want to build?

[Adam S]

so for example a debug build will be less strict, and a production build will be more strict?

[Mustafa Ozhan]

yes, and there are more of those scripts not only detekt and it is not for debug and release rather in-company vs client builds

[Adam S]

to me that sounds like you just need one convention plugin, and in it it applies Detekt and sets configuration values dynamically using the Gradle Provider API, based on a build-time variable

[Mustafa Ozhan]

It can be another workaround do you have any example for that ?

[Adam S]

yup! So I did something recently in Dokka.

The problem was that we wanted to run the tests using a different Java version. In CI/CD there's a GitHub matrix, so we can pass in a different Java version via an environment variable. And the Gradle config will read this variable, and dynamically change the version of Java

[Adam S]

for convenience I made an extension that will contain all of the variables that control a Dokka build

https://github.com/Kotlin/dokka/blob/e66f9d8711b5c1ba5e75fdcde8cfe998042c294a/build-logic/src/main/kotlin/org/jetbrains/DokkaBuildProperties.kt#L17-L49

[Adam S]

I used a Gradle Property to fetch the Java Test Version, which is convenient because it can be set either via an environment variable that's prefixed with ORG_GRADLE_PROJECT_, or in a gradle.properties file, or via the command line

[Mustafa Ozhan]

I think this can solve some of our needs i will check with the team thank you for sharing it 🙂

[Adam S]

the DokkaBuildProperties extension is created in a base plugin that's applied to all subprojects and convention plugins, so it's always available https://github.com/Kotlin/dokka/blob/e66f9d8711b5c1ba5e75fdcde8cfe998042c294a/build-logic/src/main/kotlin/org/jetbrains/conventions/base.gradle.kts#L15

[Adam S]

and then in the base Java convention, it uses the testJavaLauncherVersion variable to set the default Java launcher version for all test tasks

https://github.com/Kotlin/dokka/blob/e66f9d8711b5c1ba5e75fdcde8cfe998042c294a/build-logic/src/main/kotlin/org/jetbrains/conventions/base-java.gradle.kts#L25-L31

[Adam S]

and then because it's just a convention, subprojects can override the value if required. Which we needed to do in an integration test project, because one of the test project requires a minimum of Java 11

https://github.com/Kotlin/dokka/blob/e66f9d8711b5c1ba5e75fdcde8cfe998042c294a/integration-tests/gradle/build.gradle.kts#L22-L27

[Adam S]

generally, it's a bit of a shift in thinking. It's the biggest difference between Maven and Gradle - composition vs inheritance. You can make Gradle behave like Maven, where there's a 'parent' and it controls everything, but that's not how Gradle works best.

[Mustafa Ozhan]

Yea superficially looking it will solve some of our needs, we will give a close look definitely with a team thankfully it is public repo 🙂 Thanks a lot for sharing!

[Adam S]

my pleasure! If you want to get more info, there's also a Gradle Slack that would be better suited to more general Gradle usage questions https://gradle.org/slack-invite

[Javier]

you can solve that issue by not using precompiled plugins and using normal plugins tho

[Mustafa Ozhan]

Yea with Adam’s approach that is also a possibility