'org.gradle.java.home' makes most sense. Cheers!
On Wed, Jan 11, 2012 at 9:13 PM, Adam Murdoch <[email protected]>wrote: > > On 11/01/2012, at 10:49 PM, Szczepan Faber wrote: > > Cool. > > >'org.gradle.jvm.home' > > You mean 'org.gradle.jdk.home'? > > > I meant jvm, but Gradle will happily accept either a jvm or jdk install. > Gradle only needs a jdk if you happen to be compiling java source, and it > can often find the jdk given a jvm install. But perhaps let's call the > property 'org.gradle.java.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 > > > > -- > 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
