The support to Android signingConfig wasn't initially planned and added as last minute feature. This also forced some API in Entries that is not used in the standard scenarios (ie: Entries#getParentFile()).

We used to generate Groovydoc with every release and showcase it at the following URL but there is an issue with the deployment: https://novoda.github.io/gradle-build-properties-plugin/docs/<VERSION>

https://github.com/novoda/gradle-build-properties-plugin/blob/master/plugin/src/main/groovy/com/novoda/buildproperties/BuildPropertiesPlugin.groovy#L99

Currently the plugin appends the storeFile to the current working directory, but normally if the path starts with / that gets treated as absolute path and if it doesn't then it's treated as relative

It'd be nice if this was supported in the plugin

Currently it's kinda hard to check whether the Entries contain a certain key.

Possible workarounds are:

if (buildProperties.cli['key'].or('none').string != 'none') {
   ...
}

or

buildProperties.cli.keys.toList().contains('key')

But ideally we would expose BuildProperties.contains(String key):

if (buildProperties.cli.contains('key')) {
   ...
}

It would be better to prove a more holistic approach to provide a description/additional info message alongside the error when an evaluation failure happens.

The docs specify how you can reference properties files:

but it says file is deprecated:

where clicking through seems to link to the wrong method?

buildProperties {
    using letterboxd.properties
}

says could not find method using()

How can I get rid of the deprecation warning?

It would be better to consolidate the API to fill a properties set. Ideally file(File, String) would be deprecated in favour of from(File)

It's time to improve the automation of a release, including:

• tagging
• release to GitHub
• deploy to Bintray
• upload of GroovyDoc to GitHub pages

We can consider to start from what already done for gradle-static-analysis-plugin and improve further.

I was experimenting with the plugin on the weekend.
or support works great for missing or optional prop files. But the signing configs does not support it.

When my project is cloned, I want it to be immediately buildable. At least the debug build.

So I fiddled with the plugin and added or support to the file method in BuildProperties. It worked quite well. I could go like this

    releaseSigning {
        file file('properties/releaseSigning.properties')
        or file('properties/debugSigning.properties')
    }

But I realized, it may not be really something we want. Comparing it with include and or support on Entity, it is only necessary for signing configs.

So I'm thinking about working on addSigningConfigSupportTo to support alternatives configs if not found.

What do you think?

Following the discussion in #27:

I am also planning of removing this mechanism because not too flexible (relative paths provided by include property are now evaluated using the properties file parent folder as base). I really want to put in place something more explicit, [...] but embracing the inheritance of build properties holistically

buildProperties {
   default {
        from project.file('default.properties')
    }
    production {
        from project.file('production.properties')
        include 'default'
    }
}

Yaml is very popular format although it seems to not be supported by gradle-build-properties-plugin.
On the other hand, your plugin is awesome and I don't to stop using it, therefore I must stick to .properties format
Would you consider supporting yaml format as well?

When moving from the old coordinates (com.novoda:build-properties-plugin:1.2.1) to the new ones (com.novoda:gradle-build-properties-plugin:0.3.9), there are significant hurdles to overcome. We should have a migration guide on what's changed so it's easier for people to migrate.

title says it all missing quotes in plugin import

https://github.com/novoda/gradle-build-properties-plugin/blob/master/sample/app/build.gradle

Hi there,

After defining a fallback file source, my build immediately fails when the first file the plugin goes looking for does not exist. Have I misunderstood the purpose of fallback entries?

The following is my exact use case:

buildProperties {
    secrets {
        using(file("non-existent.file")).or(file("guaranteed-to-exist.file"))
    }
}

My expectation from the documentation is that if the plugin does not find "non-existent.file", it will load (or attempt to load) "guaranteed-to-exist.file". But, assuming I've debugged correctly, it hits an immediate FileNotFound exception.

Is this intentional behavior?

For reference, I am using version 0.4.1 taken from the Gradle Plugins Repository.

Hi there,
Are there any plans to migrate from jcenter() while repo is sunsetting ? More info here: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

It is very common situation that you have application.properties file, but on specific environment you must override it (take --spring.config.location=file://override.properties as an example).

It would be great if gradle-build-properties-plugin would support overriding properties from the command line too

I've updated my build.gradle file to include gradle-build-properties-plugin. Then I tried to load some secrets into my debug buildType and got this message:

Error:(46, 0) Could not find method buildConfigString() for arguments [MY_SECRET_KEY, com.novoda.buildproperties.Entry@249d2bfe] on BuildType_Decorated{name=debug, debuggable=true, testCoverageEnabled=false, jniDebuggable=false, pseudoLocalesEnabled=false, renderscriptDebuggable=false, renderscriptOptimLevel=3, minifyEnabled=false, zipAlignEnabled=true}, embedMicroApp=false, mBuildConfigFields={}, mResValues={}, mProguardFiles=[], mConsumerProguardFiles=[], mManifestPlaceholders={}} of type com.android.build.gradle.internal.dsl.BuildType

Is anything that I'm doing wrong?

my build.gradle file:

buildscript {
    repositories {
        jcenter()
        maven { url 'https://maven.fabric.io/public' }
    }

    dependencies {
        classpath 'io.fabric.tools:gradle:1.22.1'
        classpath 'com.novoda:gradle-build-properties-plugin:0.3'
    }
}
apply plugin: 'com.android.application'
apply plugin: 'io.fabric'
apply plugin: 'com.novoda.build-properties'

...

android {
...

    buildProperties {
        secrets {
            file project.file('parameters.properties')
        }
    }

    buildTypes {
        debug {
            buildConfigString "MY_SECRET_KEY", buildProperties.secrets['a_secret_key'].or(buildProperties.env['MY_SECRET_KEY'])
       }
    }
...

If you add your plugin to the Gradle Plugin Repository then applying the plugin would be even easier:

plugins {
  id "build-properties" version "0.3"
}

and that's it - no need for additional classpath entries!

The plugin currently requires the Android Gradle plugin, failing if it's not there.

At the moment the plugin introduce a set of build properties backed by system environment variables, eg:

buildProperties.env['JAVA_HOME']

Altho this has been proved to be useful I would prefer to let the user decide whether to define an entry in the buildProperties container and just expose a simple way of creating an instance of Entries from System.getnv() (or a map in general!).

At the moment you can't load a property named version from your properties file.

Example file, myprops.properties:

name=pirata
version=1.2.3

If you attempt to load the version property you'll always get unspecified. This happens because PojoMetaMethodSite defines a version field that collides with the Entry's one.

More on loading properties

If the specified file is not found an exception is thrown at build time as soon as one of its properties is evaluated. You can specify a custom error message to provide the user with more information.

An example of this is missing from the readme

In a couple of projects using this plugin we already have scripted another implementation of Entries backed by project or system properties. This is particularly handy to pass parameters via cli to override values defined in properties files.

I do not want to require the presence of the releaseSigning.properties for my open source project in order to allow contributors to start using the project as quick as possible.

Currently, I am simply setting android.buildTypes.release.signingConfig to null as shown below:

File propFile = file("releaseSigning.properties");
if (propFile.exists()) {
    def Properties props = new Properties()
    props.load(new FileInputStream(propFile))

    if (props.containsKey("storeFile") &&
            props.containsKey("storePassword") &&
            props.containsKey("keyAlias") &&
            props.containsKey("keyPassword")
    ) {
        android.signingConfigs.release.storeFile = file(props["storeFile"])
        android.signingConfigs.release.storePassword = props["storePassword"]
        android.signingConfigs.release.keyAlias = props["keyAlias"]
        android.signingConfigs.release.keyPassword = props["keyPassword"]
    } else {
        android.buildTypes.release.signingConfig = null
    }
} else {
    android.buildTypes.release.signingConfig = null
}

How can I do the same with the gradle-build-properties-plugin?

At the moment if the generated field/resource needs to have a different type than String the only option is to use typed accessors, eg:

buildConfigDouble 'RATE', buildProperties.bar['rate'].or{ 1.0 }.double

It would be better if all the buildConfig* and resValue* utilities exposed by the plugin worked directly with Entry instances, eg:

buildConfigDouble 'RATE' buildProperties.bar['rate'].or { 1.0 }

This will incidentally make obsolete buildConfigProperty and resValueProperty, which implicitly convert any value to String.

Different Entries implementations either use Map or Properties.
Properties already implement Map. Instead of having custom map like methods in Entries it should really be just extending Map.

Thanks to this change, the plugin will be easier to use thanks to already available map extensions in groovy.
Example: We can just use buildProperties.secrets.values() to access all values.

The README as it is now is very long and quite confusing. A new user should just be able to glance at it and understand how to use the plugin. Anything else can be covered as separate documentation (separate markdown documents in the repo).