Yesterday me & Daz talked a bit about the daemon matching and honoring gradle.properties settings for the regular gradle. I've slept on it and have some feedback. Sorry if my email is not verbose enough - I'm cutting the story short.
The current approach we aim for is: -When no-daemon build starts, we parse the gradle.properties. If the settings match the current process we happily continue. If the settings don't match the current process we execute the build in a single-life daemon. I'm leaning towards a simpler approach, e.g. always spawn a child process when gradle.properties contains process-sensitive settings because: 1. It avoids tricky process matching. Java's getInputArguments() is not reliable enough for strict matching: extra vm options of some platforms, rubbish options when some sys. properties are quoted with spaces, and possibly other problems as they usually come in clusters. 2. The reason someone configures java settings in gradle.properties is because he wants something different than the default. So, in majority of cases the client process will not match the 'desired' criteria and we will spawn the child process, anyway. So, why do we want to complicate the algorithm for a quite unusual use case? Also the more process and java configurability we introduce to the gradle.properties, the less likely it will be that the client process matches the desired context. 3. It feels like a natural step towards default daemon and (a bit of a song of future) native client. I.e. moving away from "in-process or daemon" mode towards "short-lived daemon or long-lived daemon" mode. Thoughts? Chance is I'm not seeing some obvious benefits of the original approach :) If we go for the original approach I'd still recommend avoiding getInputArguments() for process matching and figuring out a more reliable way of doing that. Cheers! -- Szczepan Faber Principal engineer@gradleware Lead@mockito
