Reg: Resolving user defined properties in ext blocks and gradle.properties

[Thirumala Reddy (తిరుమల రెడ్డి)]

Hello,

I work on Gradle integration in Android Studio and I am looking to find and understand the resolution logic for user defined properties in ext blocks and gradle.properties files. I have a project with the below listed hierarchy.

| <GRADLE_USER_HOME>/gradle.properties

| RootProject

| - - build.gradle

| - - gradle.properties

| - - FirstLevelChildProject

| - - - - build.gradle

| - - - - gradle.properties

| - - - - SecondLevelChildProject

| - - - - - - build.gradle

| - - - - - - gralde.properties

| - - - - - - ThirdLevelChildProject

| - - - - - - - - build.gradle

| - - - - - - - - gradle.properties

When I tried to use a user defined property in ThirdLevelChildProject's build.gradle file, the value is resolved to the properties defined in the following order (i.e if it's not defined in the first file, it will be looked for the next one and so on)

1. ThirdLevelChildProject/build.gradle
   
2. <GRADLE_USER_HOME>/gradle.properties
   
3. ThirdLevelChildProject/gradle.properties
   
4. RootProject/gradle.properties
   
5. SecondLevelChildProject/build.gradle
   
6. SecondLevelChildProject/gradle.properties
   
7. FirstLevelChildProject/build.gradle
   
8. FirstLevelChildProject/gradle.properties
   
9. RootProject/build.gradle
   

The order looks fine for the most of the files except for two entries. I am not sure why the <GRADLE_USER_HOME>/gradle.properties and RootProject/gradle.properties has higher precedence over many other places inside the project.

Is this resolution order is working as intended? If so could some please explain the reason behind the higher precedence given to the two locations I motioned above.

Thanks,

Thirumal.

-- 

Thirumala Reddy Mutchukota | Software Engineer, Google Inc. | Mountain View, CA.

[Thirumala Reddy (తిరుమల రెడ్డి)]

Ping!

[Adam Murdoch]

It is working as intended, but sometimes there's a difference between intended behaviour and good behaviour.

There are 4 ways that a property can be made visible for a project, with the following precedence:

1. Explicitly set by some build logic (often, but not always, the build script).

2. Specified on the command-line, or as a system or environment property.

3. Defined by a properties file.

4. Inherited from the parent project.

For #3, there are 3 places where the properties are taken from, with the following precedence:

1. From the user's ~/.gradle/gradle.properties

2. From the properties file in the project directory.

3. From the properties file in the root directory (often, but not always, the project directory of the root project).

The idea is that applying the root directory properties provides a way to set a default value for all projects, and applying the user's home properties provides a way to locally override certain values (as the properties files are often checked into VCS).

However, probably a better option for providing a default value for all projects would have been to apply the root directory properties only to the root project and rely on inheritance to provide a value for all the projects.

And, for the override case, it would probably have been better to override only those properties that are defined in the project's properties file, rather than just taking the union of the two properties file.

We're mostly stuck with this behaviour for the 2.x stream, because of backwards compatibility constraints, but could probably make some tweaks.

--

Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.com

[Thirumala Reddy Mutchukota]

Thanks for the details Adam.