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
