lazybones
lazybones copied to clipboard
Documentation Update
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']
}
}
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).