I would recommend what the git guys do with git config. You still want to debate the default... But there should be configs for a project and for a system (global). Perhaps the gradle file already provides the project level...
While command-line execution config makes sense to me... It may not for windows users. My main pt is git has this solved in a way that works well. Providing some symmetry to that may even ease adoption. So... gradle config --global daemon.on "true" And gradle config --global daemon.heap "512m" And of course gradle config --global list It seems the gradle preference is to have the user mod files directly. There is a beauty from being abstract from that... IMO Sent from my iPhone On Aug 16, 2012, at 3:15 AM, Hans Dockter <[email protected]> wrote: > We made the decision in the past that for now we don't want to switch on the > daemon by default. This is mostly because we don't recommend using the daemon > on CI boxes and people shouldn't run into issues there because they are not > aware to switch the daemon off on those machines. > > But on dev machines we really think it should be the default. One thing we > could do as a compromise is to show an info message when the daemon property > is not set at all. > > Something along the lines: We recommend to switch on the daemon on all dev > machines to give you a much better performance experience. You can switch the > daemon on by gradle --daemon-on. To learn more about the daemon look at: .... > > > The other part of the story is to provide a way on the command line to switch > the daemon on or off without touching any property files yourself (e.g. > gradle --daemon). > > Many people are not aware of the daemon. So increasing the daemon adoption > will improve the Gradle experience for many of our (particularly new) users. > > Hans --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
