in the versions example, if I didn't postfix with .int it doesn't work (didn't, about a month ago). why?

• android.defaultConfig.versionCode expects int as input so you have to use .int to force the evaluation of the Entry you provide as integer (see BuildProperties#getAt(String))

in the versions example, if I didn't postfix, would it default to string? even though it's not wrapped in "" in the properties file?

• It depends uniquely where are you using the entry: in the example above versionCode and versionName can't understand what an Entry is, therefore you have to evaluate that (via .int or .string). If instead you use one of the utilities provided by the plugin that extends the basic Android plugin DSL (ie: buildConfigInt, buildConfigString, etc) then you can save the type casting because they support also Entry as input (since #23). Also note that properties files don't support values wrapped in"".

is the buildProperties handle something defined by the plugin? OR is it a reference to the buildProperties closure which is defined (required) by the plugin?

• It's a NamedDomainObjectContainer<BuildProperties>, basically a container defined by the plugin holding BuildProperties (à la androidConfig.signingConfig, android.productFlavors, etc).

for the resource creation, is it just string resources? Or integer, dimen, color etc too?

• As mentioned in the current README the plugin provides only support for int, boolean and string on top of resValue. Other types can be added I suppose.

from gradle-build-properties-plugin.

I think this is enough to get started.

It shows what is (for me) the two common scenarios: using the values in your build script, and using the values to generate fields in BuildConfig. I tried to use variations in the naming to make it clear that the keys did not have to match a convention, nor that the file names had to match the BuildProperties handle.

I have loads of questions though - maybe we can start from here, and put the rest into /docs/README.md with a link, then separate out sections (probably one page is still enough) from there?

gradle-build-properties-plugin

External properties files support for your build scripts.

Description

Manage properties you want to keep out of version control (e.g. keys, credentials, endpoints etc.). This plugin simplifies:

• accessing properties files from your build script
• generating fields in Android's BuildConfig class with values from your properties files
• generating Android resources with values from your properties files

Adding to your project

The plugin is available from JCenter:

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    classpath 'com.novoda:gradle-build-properties-plugin:<latest-version>'
  }
}

Apply the plugin in your build script:

apply plugin: 'com.novoda.build-properties'

Simple usage

Given the following properties file, myproject/properties/version.properties:

VERSION_CODE=123
VERSION_NAME="1.2.3"

you can create a reference to it in your build script, myproject/app/build.gradle:

buildProperties {
    versions {
        file project.file('../properties/version.properties')
    }
}

android {
    ...

    defaultConfig {
        versionCode buildProperties.versions['VERSION_CODE'].int
        versionName buildProperties.versions['VERSION_NAME'].string
        ...

You can create multiple properties files. myproject/properties/api_secrets.properties:

api_client_id="abcdefg"
api_client_secret="1234567"

and you'll just need to add a handle to it (can be different from the file name) in the buildProperties closure:

buildProperties {
    versions {
        file project.file('../properties/version.properties')
    }
    api {
        file project.file('../properties/api_secrets.properties')
    }
}

android {
    ...

    defaultConfig {
        buildConfigString 'CLIENT_ID', buildProperties.api['api_client_id']
        buildConfigString 'CLIENT_SECRET', buildProperties.api['api_client_secret']
        ...

from gradle-build-properties-plugin.

Here are some of the questions:

• in the versions example, if I didn't postfix with .int it doesn't work (didn't, about a month ago). why?
• in the versions example, if I didn't postfix, would it default to string? even though it's not wrapped in "" in the properties file?
• is the buildProperties handle something defined by the plugin? OR is it a reference to the buildProperties closure which is defined (required) by the plugin?
• for the resource creation, is it just string resources? Or integer, dimen, color etc too?

from gradle-build-properties-plugin.

Addressed by #49

from gradle-build-properties-plugin.