Yeah, I was thinking something like Lift's approach to configuration files, where a series of conventional ones are applied in order (if they exist).
At the time when I wrote the plugin, there wasn't "apply from:". Hence the properties files. Could you do "apply from:configFile, to:dependencies"? Would that effectively get you within the dependencies block? ~~ Robert. On Tue, May 22, 2012 at 6:54 PM, Jason Hatton <[email protected]> wrote: > Yeah that aligns with the direction I was thinking for dependencies. > What about environment type stuff like databases setup related items > or target environment config files? Probably especially those that > might not have a viable plugin. > > Thinking out loud, > > Jas > > On May 22, 2012, at 4:35 PM, Peter Niederwieser <[email protected]> wrote: > >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
