Cool. >'org.gradle.jvm.home'
You mean 'org.gradle.jdk.home'? Cheers! On Wed, Jan 11, 2012 at 11:02 AM, Adam Murdoch <[email protected]>wrote: > > 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 > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
