Property file usage

Help/Discuss
1

Hi everyone,

I’m having a discussion with someone on github on the particulars of the gradle.properties file, hoping for some community feedback.

The main point of clarity I seek is what is the proper use of the gradle.properties file (I also don’t mean just in a gradle world, but a full development cycle world)

The specifics:
For a plugin, given the following:

buildscript {
    ext.versions = [
        jarA: '3.8.4',
        jarB: '4.1.0',
        jarC: '2.23.2'
    ]
}

My suggestion was that since these values and can be changed they are better off placed in the gradle.properties file which can then be checked into SCM, and ignored. That way a forked developer can change the values without the need to worry about conflicts when doing updates and their own environment.

The answer I got back: “Environment specific properties should go into the gradle.properties file in your Gradle user home.” which doesn’t make any sense to me.

2

In case you’re not already aware, there are two gradle.properties files to consider. One in the project directory and the other in the Gradle user home directory.

I agree with the statement you quoted, that environment specific properties should be placed in the Gradle home properties file. These should be settings such as usernames and passwords that the build may require, or perhaps settings that are only needed during CI builds but not regular developer builds. Perhaps the location of special tools could be here. These are the types of things I consider environmental.

Your example looks a lot like a list of dependency versions, so I’ll base the rest of my reply on that.
I disagree with the idea that dependency versions are environmental in nature. Dependencies are just as important as, and in fact are a part of, the project source code. I think it would be a mistake to treat them any differently. Sure, dependencies can be placed in a file external to the build.gradle file, but as a developer I would always want to know when I’ve changed them just like any other piece of source code. Having that information tracked by the scm tool is an easy way to ensure that. Since you also hinted that the list of versions could be plugin versions, I still have the opinion that those are critical pieces of source code.

1 Like