Hi Luke, All- Okay, I signed up on the Jira site and created issue #1618 : http://issues.gradle.org/browse/GRADLE-1618
Hopefully I chose acceptable categories for things- it wasn't clear what the right one would be for Daemon issues.. Since using gradle via the Daemon is a dramatically better experience performance-wise, I imagine that more and more people will start running into this issue, even though the Daemon is clearly marked "experimental". Oh, and I forgot to mention how we worked around the issue. I found something online that I'd never seen before, but which works well, although it's kind of a sledgehammer solution: The file.encoding system property is only effective if set before the VM starts up (changing it later through System.setProperty doesn't work). But you can set an environment variable called "JAVA_TOOL_OPTIONS", which is automatically checked by the java command, so this works: export JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8" But doing this effects ALL java processes on your machine, so it's not a good long-term solution... -Dave Fogel On Tue, Jun 14, 2011 at 7:39 PM, Luke Daley <[email protected]> wrote: > I've experienced this too. I actually suspect there are other places as well > where the encoding is not being handled correctly (one I can think of is POM > generation). > > Please make sure you raise an issue for this issue with the daemon. You're > right in that it should respect the environment options. > > On 15/06/2011, at 7:51 AM, David Fogel wrote: > >> We've just recently switched to Gradle for building our various >> projects, and for the most part things are working pretty well. But we >> spent a few days trying to figure out why certain tasks in our build >> were messing up character encodings of our source files (which all >> start out as UTF-8). >> >> What we finally discovered is that when the Gradle Daemon is started >> (in org.gradle.launcher.DaemonConnector.java), it doesn't copy in any >> of the program or VM arguments from the originating gradle command, or >> the existing environment settings that are set using GRADLE_OPTS or >> JAVA_OPTS. Among other things, we had been setting GRADLE_OPTS to set >> the file.encoding Java system property. But when the Gradle Daemon >> executed our gradle builds, the JVM was set to use the platform >> default, which is, for instance, Mac Roman on Mac OS X. >> >> Obviously it isn't a great idea to rely on the platform default >> encoding, but we're calling into 3rd-party ant scripts from our builds >> (in this case to concatenate and compress javascript source files), >> and those ant scripts made use of tasks which used the platform >> default (for instance the LoadFile Ant task does this). >> >> I can see there's an argument against passing on command-line args >> from the gradle command to the Daemon, but shoulnd't the Daemon make >> use of environment settings like GRADLE_OPTS and JAVA_OPTS in a same >> way that the gradle shell command does? >> >> -Dave Fogel >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
