Let's leave them where they are, I think. If we find that there is a good reason to separate some types of configuration, then we might instead look at ways to start treating external configuration as a first-class citizen of the model, so that you can declare the inputs of the build, attach descriptions to them, configure them through the IDE/command-line, source them from various pluggable locations, validate them, etc.
Then, it doesn't really matter that they happen to live in the same file. So, to finish the story, we just need some docs and a release note, I think. And perhaps a 'org.gradle.jvm.home' property, too. On 11/01/2012, at 1:03 AM, Szczepan Faber wrote: > It would be good to decide on the approach as we are working on this story. > > 1. What file should contain the setting, gradle.properties (currently > implemented but experimental) or build.properties (so the user effectively > maintains 2 files)? > > 1.1 Do we want to have different options configurable in gradle.properties > (properties, etc.) and different in build.properties (jvm options, etc.)? I'm > not sure if separating options is a good idea. For example, some build > properties might be interesting for the build master so he would actually > work with both files, anyway. So the whole reason for separation sort of > dwindles. If we allow the same configuration options in both files with a > clear precedence order then I think we can defer decision about > 'build.properties' and for now use what we have in the master. Thoughts? > > 2. Where should the file live? $rootDir/gradle is fine be me. > > Cheers! > > On Tue, Jan 3, 2012 at 10:55 AM, Szczepan Faber <[email protected]> wrote: > * In the existing $rootDir/gradle directory, eg > $rootDir/gradle/build.properties (thats $rootDir/gradle, not $rootDir/.gradle) > > I assume the 'gradle' folder will not go away soon because we have to keep > the gradle-wrapper.jar somewhere. So I would go for this option. > > Another question is what format the file should have. Properties are easy, > but it might be nice to have some structured info in there. Perhaps xml or > json would be a better option. > > I would stick with properties for now because it feels easy to introduce > conf.xml or conf.json later if we like. > > We could, if we put a little effort into it, even use a .gradle script of > some kind (possibly even an init.gradle script). > > I'm tempted to stick with a simple solution (properties) and iterate/evolve > if necessary. Though, I may not be seeing all the use cases :) > > Cheers! > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
