This is by design as far as Gradle is concerned. It makes sense to not make an assumption that the properties provided to the outer java instance wouldn't necessarily just want to be inherited by the child process that is forked off for the JavaExec task.
We should create a pass-through similar to this. A safer (but not foolproof) implementation than what is shown there is to determine what system properties are available by a default run and not pass those on by calculating the difference.
Alternate implementations to consider:
Implementing this as a gradle property would provide large coverage in terms of ways to override. Environment variable, command line, etc. Bc it can be overridden by an environment variable it'd be easy to pass system properties directly to the forked process. This would be even safer than the technique above, but it introduces yet another project Gradle property (the glut of Gradle properties for acorn projects may or may not be a problem, sounding board off Nick).
This is by design as far as Gradle is concerned. It makes sense to not make an assumption that the properties provided to the outer java instance wouldn't necessarily just want to be inherited by the child process that is forked off for the JavaExec task.
We should create a pass-through similar to this. A safer (but not foolproof) implementation than what is shown there is to determine what system properties are available by a default run and not pass those on by calculating the difference.
Alternate implementations to consider: Implementing this as a gradle property would provide large coverage in terms of ways to override. Environment variable, command line, etc. Bc it can be overridden by an environment variable it'd be easy to pass system properties directly to the forked process. This would be even safer than the technique above, but it introduces yet another project Gradle property (the glut of Gradle properties for acorn projects may or may not be a problem, sounding board off Nick).