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
