https://kotlinlang.org logo
Title
h

hmole

04/13/2019, 6:29 AM
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.
g

gildor

04/13/2019, 7:57 AM
Putting buildSrc in you buildSrc? 🤔
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
h

hmole

04/13/2019, 9:13 AM
You misunderstood. I need to share it in
buildSrc
scripts itself, not the project scripts
g

gildor

04/13/2019, 9:14 AM
Share it across multiple Gradle projects? Or just to make it available in all submodules?
h

hmole

04/13/2019, 9:15 AM
In a multiple projects of a
bulidSrc
. It can be multiproject too
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
g

gildor

04/13/2019, 9:35 AM
buildSrc should have submodules
In theory it may have, but I don't see why do you need this, buildSrc is module itself
h

hmole

04/14/2019, 5:38 AM
Same reason why you would have different modules anywhere - to separate different domains.
g

gildor

04/14/2019, 1:00 PM
So, what is problem? Those buildSrc submodules do not work?
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
h

hmole

04/14/2019, 6:48 PM
@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?
g

gildor

04/14/2019, 11:18 PM
Create one more module on buildSrc, put version there in constant/object and add this module as dependency to both projects
of course it makes sense to put then in different modules
Or just to different plugins
h

hmole

04/15/2019, 5:32 AM
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"
g

gildor

04/15/2019, 5:35 AM
You have multiple modules in buildSrc?
For buildSrc/build.gradle itself only valid way is to declare them on in this file itself or read from properties
h

hmole

04/15/2019, 6:09 AM
Yes properties sounds like the way to go, but they're not typesafe sadly
g

gildor

04/15/2019, 6:14 AM
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
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
h

hmole

04/15/2019, 6:45 AM
Probably will to that. Shame about buildSrc inside buildSrc not working though...😕
g

gildor

04/15/2019, 6:47 AM
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