one last thing, constants, currenrly in ext block, kotlin dsl samples use buildSrc -- ill need to mo...

# gradle

[ursus]

one last thing, constants, currenrly in ext block, kotlin dsl samples use buildSrc -- ill need to move to kotlin dsl incrementally -- can groovy code see buildSrc objects? or will kotlin dsl files I migrate work with ext constants? (dependency artigact names)

[gildor]

can groovy code see buildSrc objects

Sure, buildSrc is just a part of build classpath

[gildor]

will kotlin dsl files I migrate work with ext constants

Also will work, but it will be something like
ext[“someConstant”]

[gildor]

but I wouldn’t recommend to move version to buildSrc, though, it very handy, autocomplete in Kotlin dsl and so on, but every change in buildSrc cause full recompilation of the project, so it quite painful

I don’t have perfect solution, but even just keeping constants in gradle.properties is better imo

Also recently we stopped using constants, and define version using java-platfrom plugin and use them in all modules without version, something like this:
implementation “some:library”

But it’s not something kotlin dsl specificc

[ephemient]

https://github.com/gradle/gradle/issues/9224 should help with buildSrc changes forcing everything to be recompiled

[ephemient]

using included builds should be the way forward https://github.com/gradle/gradle/issues/14044

[ephemient]

also the kotlin gradle dsl lets you write

kotlin
val foo: Any? by project // ext["foo"]
var bar by ext("1") // ext["bar"] = "1"

[gildor]

using included builds should be the way forward 

Included builds will not help, if you have only 1 included build with all your dependencies which applied to all modules, it will still trigger recompilation of everyhing

You can split dependencies to multiple modules, but it looks as huge overkill for this use case for me and I would just avoid using any constants for dependencies until gradle provide proper way to handle this (java-platform mitigates this problem thoug)