https://kotlinlang.org logo
Join Slack
Powered by
Hey I was wondering if it was possible to use sett...
# getting-started
t
Hey I was wondering if it was possible to use settings in the root gradle.properties in my sub-projects? I tried accessing like this 
val test: String by rootProject
but that just produces null. Thank you in advance.
v
They are available in each project. Actually in the subprojects you even cannot have a dedicated file. So just access them the same way you would access them in the root project.
Besides that the question is probably more suited for #gradle 😉
t
Ah I didn't see there was a gradle channel
v
And that your snippet for sure does not produce 
null
as your type is non-nullable
t
Er well more like it just errors out
v
Well, as I said, if the Gradle property is defined, 
val test: String by project
should work perfectly fine.
If it can be absent legally, make the type nullable
t
`Cannot get non-null property 'ktor_version' on root project 'socket' as it does not exist`` In my root project's gradle.properties I set 
ktor_version=2.1.3
then in my module socket I try accessing it via 
val ktor_version: String by project
Then I receive that error
Also using 
val ktor_version: String by rootProject
doesn't work either
v
Don't use "by rootProject", if either does not work, the other also wont
What I guess from your vague description is, that 
socket
is not a subproject, but the root project of an included build
t
Ah
v
There it does of course not work, an included build is a separate thing
If you only work on *nix, you could e. g. use a symlink to link the root builds properties file to the sub build
Or you could just copy it and have a validation task that makes sure that any changes are done in both files
...
t
Symlink my gradle.properties in root to all my sub modules?
v
If what you call "sub module" is an own build you include using composite builds and you want those properties there too, why not? If you only work on systems where symlinks are supported that is.
But I actually would give each build its own properties file
And especially when it is about versions, don't use properties, use a version catalog
âž• 1
This can easily be shared between the builds and projects
You could even publish it and use it in otherwise unrelated builds like a library
t
Ah, I thought I'd try to share versions because I have 2 other modules that only access ktor's websocket client and my socket module that handles the socket
Version catalog? I've never heard of that before do you by chance have an article explaining that more in-depth?
Sounds pretty cool to learn
v
t
Gotcha, thank you
👌 1
212 Views
Open in Slack
PreviousNext
Powered by