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
