This message was deleted.
# community-support
s
This message was deleted.
j
Wops, I am even following that issue for a long time and I totally forgot about it
any reason to use gradle-local.propeties instead of local.properties?
v
• personal preference • it is what the gradle-properties-plugin uses (don't use it, it currently totally destroys task configuration avoidance) • they are still Gradle properties, just local to the work tree
thank you 1
👍 1
j
problem is there are other tools like AGP which uses local.properties so maybe it is possible to get a “duplicated file”
v
That AGP uses
local.properties
is imho another reason to name it
gradle-local.properties
. Besides that I guess they just introduced it due to the lack of official support for such a file and they can just use normal project properties if official support were present.
👍 1
j
what about environment variables?
I think I would use this order: • command line, as set using
-D
gradle-local.properties
in the project’s directory, then its parent project’s directory up to the build’s root directory • Environment variables <--------- •
gradle.properties
in
GRADLE_USER_HOME
directory •
gradle.properties
in the project’s directory, then its parent project’s directory up to the build’s root directory •
gradle.properties
in Gradle installation directory
I think it has sense cli and local properties that can be codegenerated on CI are over Environment Variables. But I am not sure if they should go above home directory one, or after it
v
That shouldn't change from how it is already. Currently you have • command line (-D for Gradle properties, -P for project properties) • environment variables and system properties (I'm not sure right now which has precedence) • various gradle.propeties files As you can specify environment variables and system properties also from the command line, I think they should take precedence over
gradle-local.properties
, so your line 2 and 3 swapped
👍 1
thank you 1