We've been moving to use Kotlin DSL and therefore moving the dependencies to `buildSrc` as a `depend...

# gradle

[pablisco]

We've been moving to use Kotlin DSL and therefore moving the dependencies to buildSrc as a dependendies.kt file. However we have tests inside buildSrc so the build.gradle.kts inside buildSrc has dependencies too. Anyone has or can think of a way to use the dependencies from the build script in the buildSrc folder?

[mbonnin]

I've had the same question and ended up duplicating the buildSrc dependencies. I didn't have a lot. Maybe moshi and okhttp

[gildor]

yes, you have to specify dependencies explictly again, there is just no way to build dependecies.kt without building buildSrc

[gildor]

you of course can move them to some properties file and read it first in buildSrc/build.gradle and than in dependencies.kt

[pablisco]

One thing I've thought about, but not tried, is to put the dependencies in a kts instead of a kt and then apply the script with the dependencies. Then have to apply the script to all the build scripts, but can be done inside a allProjects {} block. Not sure if the autocomplete would work on that case...

[pablisco]

If that works wouldn't even need to use buildSrc unless you have internal plugins

[pablisco]

Can’t seem to make it work. the script complains about this:

Don't know how to generate outer expression: Class: class Libraries

🤔
The dependencies file has something like:

object Libraries {
  ...
}

It looks like we may not be able to declare new classes in a *.gradle.kts file 😞

[pgreze]

After consideration, I’ve decided to extract library declaration as a separate standalone file in gradle/ because it felt it was the “cleanest” way to share setup between buildSrc and main project

[pablisco]

@pgreze how exactly?

[gildor]

Just .properties file, read it from buildSrc/build.gradle and from dependencies.kt

[louiscad]

xxxx.properties file

[gildor]

probably read buildSrc/gradle.properties is good option, at lest you don’t need to read it in buildSrc/build.gradle it will be available in project properties

[pgreze]

@pablisco apply from: “$projectDir/gradle/dependencies.gradle.kts”

[pgreze]

Properties file is also possible but usage may not be so good looking, no?

[gildor]

Most probably it will not work properly

[pgreze]

I believe it was using Groovy at this time but please explain why it may not work

[gildor]

Because it will not give you any type safety, or even worse, you just cannot use declarations from this script easily (only using dynamic Gradle magic)

[pgreze]

about type safety, properties file is even worse IMHO
About cannot use declarations from this script easily I believe you, I never stopped facing strange issues with Kotlin DSL.

[gildor]

It’s not a “strange issue”, it’s just way how Kotlin scripting works, it’s compile-time type safe and apply is runtime application, so essentially compiler don’t know content of this script

[gildor]

about type safety, properties file is even worse IMHO

No, if you use property delegation syntax>
I actually mean not type safety in general, just that it will work in terms of adding this to scope of current script, but you just have no way to access those members

[pablisco]

I tried that @pgreze but it wouldn't resolve the object singletons that we use to namespace each type of dependencies 🤔

[pgreze]

yeah sorry @pablisco I realized I was using my old Groovy based memory. With kotlin dsl you’ll have to use something else

[gildor]

With Groovy it’s just dynamic, you can do the same in Kotlin using Kotlin DSL groovy interop, but it’s pretty awkward, I believe properties file is the only simple way

[pablisco]

Do you have an example with property files? Does it generate values that can be auto completed?

[gildor]

Unfortunately no, you have to map them manually (property delegates wor well for this, it fails fast and decrease repeating of property names).
By the way there is some properties autocomplete on IDE level in Idea, but not sure that it works with Kotlin DSL (if it doesn't, probably make sense to create an issue), but in any case it will not be just Kotlin complition and it wouldn't be compile time type safe, but probably for buildSrc it's not so big problem, it's earliest stage of build configuration, so it will fail fast
Do you have a lot of dependencies in your buildSrc itself? If they are related, maybe BOM would be better choice (bit it's different level of complexity of course)
Tho if it's manageable amount of dependencies in buildSrc itself (for example you have dozens of dependencies in your dependencies.kt and let's say 5 in buildSrc), I would just use properties as simplest solution
I agree, it's suboptimal, but it's probably the best what you can do now.
Not sure that Gradle has some feature request about it, but it definitely need one, I heard that they thinking about solution, but don't have any particular information. Also, you can discuss it in Gradle's official Slack, just to get some insight from Gradle team, maybe they could point to some existing issues

[pablisco]

Yeah, we only have 3 dependencies in buildSrc and some of the code in there I'm planning to refactor to use extension functions. Plus, probably makes sense to move the tests for the build code in buildSrc to a different module instead of having them there. Leaving the code in there.

[gildor]

Why do you want to move tests for buildSrc into a different module?

[pablisco]

That way we don’t have the test dependencies in the buildSrc folder

[gildor]

Yeah, but it complicates build logic, not sure what would be better