What's the solution for sharing dependency notatio...

# gradle

[hmole]

What's the solution for sharing dependency notations/versions in a typesafe way across different scripts of multimodule buildSrc? I tried putting buildSrc in my buildSrc 🤯 but sadly it didn't work.

[gildor]

Putting buildSrc in you buildSrc? 🤔

[gildor]

In general yeah, this is the way, create a file in buildSrc/src/main/kotlin (or java, or groovy) that just has some version declarations, like in case of Kotlin it may be top level property, or (which I prefer) an object with version properties, the same you can do to share dependency string itself, not just version

[hmole]

You misunderstood. I need to share it in buildSrc scripts itself, not the project scripts

[gildor]

Share it across multiple Gradle projects? Or just to make it available in all submodules?

[hmole]

In a multiple projects of a bulidSrc. It can be multiproject too

[hmole]

project/buildSrc/module1/build.gradle.kts
project/buildSrc/module2/build.gradle.kts

I want theese build files to be able to reference dependency notation in a typesafe way

[gildor]

buildSrc should have submodules

[gildor]

In theory it may have, but I don't see why do you need this, buildSrc is module itself

[hmole]

Same reason why you would have different modules anywhere - to separate different domains.

[gildor]

So, what is problem? Those buildSrc submodules do not work?

[gildor]

In general I'm still not sure about your case, if you want to separate domains completely, use plugins instead of just classpath, move all your dependencies to plugin (or a few plugins) and apply it explicitly to modules when you need some part of configuration, so you will get real encapsulation, because even if you have multiple submodules in buildSrc and it will work (which I believe should work, just add them to buildSrc/settings.gradle), both of those modules will be added to all suodules of the project without any encapsulation, so I really don't see real gain

I'm still don't know much about your case, would hard to recommend something specific

[hmole]

@gildor I'm talking about domains between buildSrc code. For example I have 2 modules that generate code and both use kotlinpoet as a dependency. One is generic for android, and other is a very specific to my workplace build infrastructure. Of course it makes sense to put them in different modules. Now both build.gradle.kts of these modules have a dependency on com.squareup:kotlinpoet:1.2.0. You see how the dependency notation is duplicated between files? That's what my original question refers to - how to avoid it?

[gildor]

Create one more module on buildSrc, put version there in constant/object and add this module as dependency to both projects

[gildor]

of course it makes sense to put then in different modules

Or just to different plugins

[hmole]

Again you misunderstood me. I need to share dependency between scripts of buildSrc modules, not sources of buildSrc modules. That's why I was talking about "buildSrc inside buildSrc"

[gildor]

You have multiple modules in buildSrc?

[gildor]

For buildSrc/build.gradle itself only valid way is to declare them on in this file itself or read from properties

[hmole]

Yes properties sounds like the way to go, but they're not typesafe sadly

[gildor]

You can provide type safe accessor for them in your buildSrc but in general yeah, it’s still the place where we don’t have proper type-safe way to decleare some configurations

[gildor]

In theory you can of course create module and add it to buildscript classpath of buildSrc, but I believe it would be overengeniring, much easier just read properties and validate them on buildSrc init

[hmole]

Probably will to that. Shame about buildSrc inside buildSrc not working though...😕

[gildor]

buildSrc inside buildSrc sounds for me also as overengineering, but maybe if you have so complex buildSrc you could just move it to own project so this project may have own buildSrc