Documentation Update

[Ronald Kurr]

I have a documentation update that I would like to make but I'm unsure if there is a pull-request mechanism for the wiki. I wanted to apply some exclusions to my templates but found that the documentation did not match the code. Once I read the code I figured things out and wanted to update the documentation so others wouldn't have to go through the same process. Here are my suggested changes:

Use the most current plug-in:

buildscript {
    repositories {
        maven {
            url 'http://dl.bintray.com/pledbrook/plugins'
        }
    }

    dependencies {
        classpath 'uk.co.cacoethes:lazybones-gradle:1.2.3'
    }
}

apply plugin: "uk.co.cacoethes.lazybones-templates"

Use a different exclusion property than the one that is documented. I also added a property to hold the default exclusions to keep things DRY.

ext.globalExcludes = ['**/*.swp', '.gradle', 'build', '.idea', '*.iml', 'VERSION', '**/.retain']

lazybones {
    // global exclusions
    packageExcludes = globalExcludes
    repositoryUrl = 'https://api.bintray.com/content/somebody/somewhere'
    repositoryUsername = bintrayUsername
    repositoryApiKey = bintrayApiKey
    publish = true

    // template specific exclusions
    template( 'my-templatei' ) {
        // the global exclude is ignored in this case so we have to re-specify them
        packageExcludes = globalExcludes + ['docker/artifacts']
    }
}

[Peter Ledbrook]

I think your issue may be down to using the method name, packageExclude(), as if it were a property. For example, this won't work because packageExclude is not a property:

lazybones {
    packageExclude = globalExcludes
    ...
}

Another thing to be aware of is that you overwrite the existing exclusions if you set the packageExcludes property. But if you use the packageExclude() method instead, you append extra exclusions. This saves you having to maintain a list of global excludes in the example you've given.

This behaviour of setting properties overriding existing values and methods appending to them is a convention that runs throughout Gradle.

I think in this case the Template Developers Guide could do with a change that clarifies this behaviour, since there is not guarantee that users will be that familiar with Gradle (or Groovy for that matter).