My recommendation is to keep most, if not all, information in Gradle build
scripts. In most cases, I see little value in moving information into a
properties file. You lose a lot of flexibility, but what exactly do you
gain? You might just as well move the information into a separate .gradle
file, a mechanism that is supported out-of-the-box. To give an example, for
dependency management I often introduce a dependencies.gradle with content
like this:
ext.libs = [
junit: "junit:junit:4.10",
spring_core: "org.springframework:spring-core:3.1.0.RELEASE",
...
]
I then apply this script to the main build script with:
apply from: "properties.gradle"
And use it like this:
dependencies {
compile libs.spring_core
testCompile libs.junit
}
Keeping dependency declarations in a build script has several advantages
over a properties file:
- No code needed for handling properties files
- No pollution of global namespace (all properties are prefixed with "libs")
- Full Groovy/Gradle language at your disposal
The latter means that I can use all supported notations for declaring
dependencies. For example:
def springVersion = "3.1.0.RELEASE"
ext.libs = [
junit: dependencies.create("junit:junit:4.10") {
exclude module: "hamcrest-core"
},
spring: [
"org.springframework:spring-core:$springVersion",
"org.springframework:spring-jdbc:$springVersion"
]
]
These are just a few examples for things that you cannot do with properties
files.
--
Peter Niederwieser
Principal Engineer, Gradleware
http://gradleware.com
Creator, Spock Framework
http://spockframework.org
Twitter: @pniederw
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Best-Practices-for-storing-common-configuration-values-tp5709823p5709828.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
