Best practice for gradle.properties and SCM

Old Forum
1

As far as I understood, the best practice for the gradle.properties is to keep it outside of version control, because team members may use it to customize builds, and it is not desirable to have them accidentally commit changes to that file.

This is reflected here: http://chimera.labs.oreilly.com/books/1234000001741/ch04.html “Using gradle.properties is viable only if it can be kept out of source control though a mechanism like the .gitignore file or the svn:ignore property, or a similar technique appropriate for the version control system in use.”

I am aware the gradle manual suggests the opposite: http://www.gradle.org/docs/current/userguide/build_environment.html “While it’s possible to configure these in your local environment via GRADLE_OPTS or JAVA_OPTS, certain settings like JVM memory settings, Java home, daemon on/off can be more useful if they can versioned with the project in your VCS so that the entire team can work with consistent environment.”

and Peter also explicitly suggests to use gradle.properties in SCM: http://stackoverflow.com/questions/17262856/gradle-how-to-set-the-project-name-group-version-plus-source-targetcompatibi

So there seems to be two schools of thought: One school that recommends keeping the gradle.properties under version control to make sure all team members (or CI build environments) use the same defaults at the risk of one commit breaking all other builds. The other school recommends leaving gradle.properties out of version control to allow individual developers to customize the build process without impacting the other build environments, at the risk of having very different build environments and thus inconsistent build results.

While both views are viable, I think it might be nice if the gradle community found a single best practice approach that combines the best of both worlds. Meaning one file with properties to share among team members for a single given project, and one file with custom properties overriding the defaults.

This is somewhat related to the boilerplate code necessary to load settings from other property files:

http://issues.gradle.org/browse/GRADLE-1419

Thoughts?

2

Project-level ‘gradle.properties’ files should always be under source control, period. User-specific properties belong into ‘~/.gradle/gradle.properties’, and override project-level properties.

3

I stand corrected. So probably it usually is not useful to set org.gradle.java.home in the gradle.properties, when it is likely to be different in diverse teams.

4

So looking around a bit on github, I find the following:

Some 2K repositories seem to list ‘gradle.properties’ in their .gitignore, blissfully ignorant of the orthodox rule to always put gradle.properties into SCM: https://github.com/search?q=+“gradle.properties”+in%3Afile+&type=Code&ref=searchresults (substracting all results from files in specific programming / markup languages)

Some 18K projects have a gradle properties in the git repo: https://github.com/search?p=100&q="gradle.properties"+in%3Apath&ref=searchresults&type=Code

Regarding the variables from http://www.gradle.org/docs/current/userguide/build_environment.html: Some 1K people seem to put them into gradle.properties commented out https://github.com/search?p=94&q="gradle.properties"+in%3Apath+"%23+org.gradle."+in%3Afile&ref=searchresults&type=Code

Those 1K I substracted from large search result numbers below. Looking at the variables in detail (adding e.g. ’ “org.gradle.jvmargs=-Xmx” in:file ’ to the search):

Plenty (~11K) set the org.gradle.jvmargs to something, usually memory settings Plenty (~9K) set the org.gradle.parallel=true Few (400) set the org.gradle.configureondemand=true (it is still new, incubating and has little impact)

Few (256) set the org.gradle.daemon=true Almost nobody sets org.gradle.daemon.java.home

This also means (unless I miscalculate) that roughly 8K of projects do not use any ‘org.gradle.*’ property in their gradle.properties. Looking here and there, it seems to me that some people put their dependency versions into gradle.properties, and others put their release data (version, POM details, credential placeholders) into their gradle.properties.

My impression from looking at several of those files was that few people mixed these approaches.

So, while the community usage seems to agree that gradle.properties should be in SCM, there is less agreement about what should or should not go into it, there seems to be 3 use-cases that do not get mixed:

  • put org.gradle.parallel=true and memory tweaking into gradle.properties * put dependency version into gradle .properties * put releasing data into gradle.properties

Given that the latter two are often subject to minimal scripting (such as adding a -SNAPSHOT suffix or build number or such), maybe they are put into some .gradle file more often instead.