What s the solution for sharing dependency notations version

Question

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` exploding head but sadly it didn t work

gildor · Answer

Putting buildSrc in you buildSrc thinking face

gildor · Answer

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 · Answer

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

gildor · Answer

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

hmole · Answer

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

hmole · Answer

`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 · Answer

buildSrc should have submodules

gildor · Answer

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

hmole · Answer

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

gildor · Answer

So what is problem Those buildSrc submodules do not work

gildor · Answer

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 · Answer

< 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 · Answer

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

gildor · Answer

gt of course it makes sense to put then in different modules Or just to different plugins

hmole · Answer

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 · Answer

You have multiple modules in buildSrc

gildor · Answer

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

hmole · Answer

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

gildor · Answer

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 · Answer

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 · Answer

Probably will to that Shame about buildSrc inside buildSrc not working though confused

gildor · Answer

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