On 01/10/2011, at 3:58 AM, Luke Daley wrote: > Hi, > > 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? > > What I want to do change SystemPropertiesCommandLineConverter to merge > System.properties with any properties (specified with -D) on the command > line. This would also mean that it would never be valid to do > System.getProperty() in the gradle code, except if it's a jvm property that's > read on startup. Another option would be to also update System.properties > with the override values from the command line but that seems unsafe to me as > you could get wrong values. > > Consider: > > JAVA_OPTS=-Dfile.encoding=abc gradle -Dfile.encoding=def someTask > > If we did update System.properties with the overrides we would lose the > information on what the real file encoding is. However, either way if we read > file.encoding from startParameter.systemProperties we are going to get the > wrong value. > > My proposed solution is to have startParameter.systemProperties return a > merged map of System.properties + any properties from the command line > (command line properties taking precedence). For special properties like > file.encoding, we are just going to have to know that that *has* to be read > from System.properties. > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
