JAVA_OPTS needs to be escaped about sls-packaging HOT 6 CLOSED

gradlew doesn't run in the target environment, it's part of the gradlew distribution.

from sls-packaging.

Then the bug must be elsewhere. Repro steps:

1. Set JAVA_OPTS to -Dhello=hi|touch my-file-here
2. Restart the service
3. Observe that my-file-here is created in the Java service's working directory

I have a service named alchemist-foundry that has a shell script located at service/bin/alchemist-foundry that looks rather similar to the gradlew script here, though with a different header:

##############################################################################
##
##  alchemist-foundry start up script for UN*X
##
##############################################################################

At the bottom that script contains these lines which seem to be where the bug is:

# Split up the JVM_OPTS And ALCHEMIST_FOUNDRY_OPTS values into an array, following the shell quoting and substitution rules
function splitJvmOpts() {
    JVM_OPTS=("$@")
}
eval splitJvmOpts $DEFAULT_JVM_OPTS $JAVA_OPTS $ALCHEMIST_FOUNDRY_OPTS

This must be used as part of the Gradle default start script task defined at https://github.com/palantir/gradle-java-distribution#packaging

from sls-packaging.

Ok, so it’s a bug in Gradle’s generated shell script. We could look at moving away from Gradle’s generated shell script, we probably want to do some things differently than it does anyway.

from sls-packaging.

Specifically https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/resources/org/gradle/api/internal/plugins/unixStartScript.txt added in commit gradle/gradle@a7a8fec

from sls-packaging.

@uschi2000 is tracking this one

from sls-packaging.

Resolved in #85. We have another couple of updates to make before releasing, but this has now been addressed.

from sls-packaging.