Best practice for and SCM

(Thibault Kruse) #1

As far as I understood, the best practice for the 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: “Using 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: “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 in SCM:

So there seems to be two schools of thought: One school that recommends keeping the 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 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:


(Peter Niederwieser) #2

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

(Thibault Kruse) #3

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

(Thibault Kruse) #4

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

Some 2K repositories seem to list ‘’ in their .gitignore, blissfully ignorant of the orthodox rule to always put into SCM:“”+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:""+in%3Apath&ref=searchresults&type=Code

Regarding the variables from Some 1K people seem to put them into commented out""+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

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

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 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 * put dependency version into gradle .properties * put releasing data into

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.