Getting a live view of environment variables (Gradle and JDK 9)
me at noctarius.com
Fri May 19 06:08:06 UTC 2017
Couldn't the gradle call transfer his view of the environment? I know that's a workaround but it would solve the issue, wouldn't it?
On May 19, 2017 8:02:58 AM GMT+02:00, Jochen Theodorou <blackdrag at gmx.org> wrote:
>On 16.05.2017 19:46, Uwe Schindler wrote:
>> I still don't understand why you need to change the environment
>variables of the actual process. I was talking with Rémi about that
>last week, and it's not obvious to me why you need that. Sure, it is
>easier to change the environment of the actual process and then spawn a
>child process for some non-java build tool like GCC or even another
>standalone java program with option fork=true. But: Why not use the
>ProcessBuilder API when spawning those childs? So you just add an
>"official" build API inside Gradle (an official one, documented that
>allows Gradle plugins to modify the environment variables for the
>current build running). If you missed to add such an API from the
>beginning (IMHO its essential for a build system like Gradle), then you
>now have to tell your users: "Sorry we did something wrong and all our
>(bad) hacks to allow you to change environment variables are no longer
>working in the future, so please change your code. We are so sorry!"
>the daemon outlives the gradle call, and the next gradle call can be
>done in a changed environment, thus the need to update the daemon.
>Spawning a child process each time would be very bad for performance.
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
More information about the core-libs-dev