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
