We have a similar property in our build scripts. I set it up a bit differently. A developer can drop a developer.properties file in their workspace that can override defaults that are in the gradle.properties file. After that our approaches are the same. The developer can use a develop-example.properties file as a starting point. I have to admit I like the gradle-example.properties approach since it doesn't require any coding support in the build scripts. I am assuming all the defaults are probably in the gradle-example.properties file? I will try that out in the next project and see how I like it.
These approaches make on-boarding a developer really easy. You tell them just run a gradle setupEnvironment task and they are off the races. I haven't taken it as far as setting up things like Tomcat but to be honest that might be just a matter of time. I can throw away that painful Word document that tells a developer how to setup their environment. On Wed, May 23, 2012 at 12:44 AM, Ken Sipe <[email protected]> wrote: > Peter, > > I do see a value in property files... > > The gradle.properties file is auto read... so if it isn't there, there > isn't a failure... if it is it is used. I use this for properties that are > based on individual preference... then I check-in a > gradle-example.properties file for the preferred structure. Example: > > tomcat_dir = /opt/appservers/apache-tomcat-6.0.35 > > This property is in the gradle.properties file... but isn't checked in... > it is specific to my env. > > Your approach makes sense to me... but do you have a suggestion for this > need? > > Ken Sipe | [email protected] | blog: http://kensipe.blogspot.com > > > > On May 22, 2012, at 4:35 PM, Peter Niederwieser 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 > > >
