Getting a live view of environment variables (Gradle and JDK 9)

Kirk Pepperdine kirk.pepperdine at
Tue May 16 22:53:02 UTC 2017


> On May 17, 2017, at 3:11 AM, Cédric Champeau <cedric.champeau at> wrote:
> Hi Uwe,
> I already explained multiple times why we need this. Short answer: because
> we must. Slightly longer answer: because the build environment, the daemon,
> has to reflect the environment from the CLI (or the IDE, in case we call
> using the tooling API), at the moment the build is executed. Why? Because a
> user wouldn't understand that a script which does:
> println System.getenv('MY_VAR')
> doesn't print "foo" after doing:
> MY_VAR=foo gradle printVar

I disagree, this would be totally expected behavior. The daemon and this process would run in different shells and I am unaware of any daemon process that auto-magically reconfigures it’s self to adapt to any other arbitrary shell’s changed environment variables. In fact, IMHO, this seems like a fundamentally flawed way for the deamon process to behave. I believe the client communicating with the deamon that should be providing information to the daemon.

Kind regards,

More information about the core-libs-dev mailing list