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

Reply via email to