On 01/10/2011, at 6:59 AM, Luke Daley wrote: > On 30/09/2011, at 9:38 PM, Adam Murdoch <[email protected]> wrote: > >>> While trying to right some daemon tests I came unstuck because system >>> properties weren't handled the way I expected them to be. I've tracked it >>> down, and our usage of them is a bit unstructured. >> >> I'm not sure what the problem is. Can you explain it a bit more? > > It's just inconsistent. I want to be able to specify the daemon idle timeout > on the command line, but it's currently read directly from GRADLE_OPTS in one > spot and System.properties on another. In both cases specifying via the > command line doesn't work.
Ideally, I don't want any of our code to do anything with GRADLE_OPTS, except for the shell scripts. > > I apologise for the previous email, it was pretty incoherent. > > What I want to do is establish the rule that we read all sys props that > affect the way gradle works via the start parameter. In other words, we should model all our configuration options, and convert environment variables or system properties or -D command-line options or entries in ~/.gradle/gradle.properties or whatever, into properties on some configuration object(s) as early as possible? I think this makes a lot of sense. I would probably think about busting up StartParameter into a few pieces, rather than just jamming more stuff in there. We already have some logging parameters split out in LoggingConfiguration. I can see 3 chunks: * The logging configuration. Includes showStacktrace, colorOutput still on StartParameter. Probably the settings in DefaultColorMap too. * The configuration used to define how the build should be launched. This is more or less BuildActionParameters (system properties, environment vars, current dir). Perhaps user home dir, cache usage from StartParameter. Daemon timeout could go here, too. * The configuration used to configure a build (search upwards, project properties, settings script, build file, project dir, init scripts, profile) * The configuration used to execute a build (task names, dry-run, excluded task names). For system properties, we could do something like: 1. On start, the daemon client would take a copy of the current jvm's system properties (which would happen to include those specified in GRADLE_OPTS). 2. Parse the logging and -g command-line options. We'd also handle the 'gradle.user.home' system property and 'GRADLE_USER_HOME' environment variable here (moving the handing out of StartParameter). Remove 'gradle.user.home' from the copy. 3. Parse $userHomeDir/.gradle/gradle.properties, and update the copy to override any system properties specified in there. 4. Apply the -D command-line options, and update the copy to override the appropriate system properties. 5. Parse the remaining 'launch the build' configuration. This would include handling 'org.gradle.daemon' and 'org.gradle.daemon.idletimeout'. Remove these system properties from the copy. 5. For those system properties which we know cannot be changed after the jvm starts (file.encoding), we look for a daemon which was started with those system properties. If there is no such daemon, we start a new one. Remove those system properties from the copy. If we're not using the daemon, fail if any such property does not make that of the current jvm. 6. Pass the copy across to the daemon 7. Daemon updates the system properties of the jvm using the copy. 8. During configuration, parse $projectDir/gradle.properties, and apply any system properties defined there. Fail if any such property is one which we know can only be applied at jvm startup. 9. At the end of the build, the daemon restores its original system properties. We'd want this to work the same way for all interfaces for invoking Gradle: command-line, tooling API and gui. There's also a set of properties which we should never update, such as 'user.name', 'file.separator', etc. We should fail if any such property is specified. We also want to prevent changing things such as the system classloader, security manager, and so on. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
