This message was deleted.

Using extra properties is basically always a crutch and should be avoided where possible. It works in Groovy as it is a highly dynamic language where something just has to be present at runtime to work. For the better and the worse. Kotlin in the other side is a type-safe statically typed language, where you get much more helpful errors if you mess up the syntax and already at compilation time, and where you due to that can have an amazingly better IDE support. But it means that for Kotlin things have to be there at compile time. So for things like extensions, Gradle extracts the

plugins { ... }

block, applies it to a separate dummy project, then investigates which extensions were added by the plugins and generates type-safe accessors for them. But this is only done for build scripts, not for settings scripts. Probably because it would need precious build time and is rather seldomly necessary. So from an init script alone the way with the extensions is probably the best you can achieve. Otherwise your would need something that is added to the classpath that then provides the accessors pre-created, or maybe a holder class for the constants and just the builder class is added as extension, so that you just need one accessor or once the manual looking into the extensions.

got it, thank you! since that init script would have been in our custom gradle distribution - i can just fall back to provide the constants in a jar that I can add to the distribution's

lib

, that way it would be there for all the scripts no matter what. the question is: to minimize boilerplate required in the project, there a way to add our package with the custom constants (maybe even custom logic) to the list of packages that are [imported by default for scripts](https://docs.gradle.org/current/userguide/writing_build_scripts.html#script-default-imports) when a build is using our custom distribution?

You could either put your classes into one of the packages that are auto-imported, they are not sealed. Or if you build your custom distribution from source, you could of course change the respective code. I don't think you can change it with some property or init code.

Huh, this has been a lot more complicated than i expected... So I created a jar with a class and a couple of extenstion methods and properties in the

org.gradle.api

package, (because that's supposed to be imported by default... ) first i added this jar to the custom gradle distribution zip's

lib

folder and the

lib/plugins

folder, but build scripts does not seem to be picking up stuff from either... then i tried by adding the class files into the distribution by adding them to the

lib/gradle-kotlin-dsl

jar - now the build scripts saw the object i added - but i still had to manually import it: this fails:

println(MyDumbObject.someProperty)

this succeeds:

import org.gradle.api.MyDumbObject
println(MyDumbObject.someProperty)

not sure why. also any extension properties or functions are just not picked up... I am pretty sure i am missing something - but don't know what. there doesn't seem to be any guides online on how to add classes to a custom gradle distribution - only init scripts and properties...