I need the java executable to run a java -jar from a cloudfoundry task command.
Here is how I try to run the task:
cf run-task bignibou-batch "java -jar bignibou-batch/build/libs/bignibou-batch.jar"
Here is the error message I get:
2016-12-24T12:53:30.002+01:00 [APP/TASK/358e02df/0] [ERR] bash: java: command not found
My manifest uses the java buildpack as follows (see bignibou-batch
app at the bottom):
---
buildpack: https://github.com/cloudfoundry/java-buildpack.git
memory: 1024M
env:
APPLICATION_URL: http://bignibou-server.cfapps.io/
APPLICATION_MAIL_NO_REPLY_ADDRESS: [email protected]
SPRING_PROFILES_ACTIVE: cloud
applications:
- name: bignibou-server
path: bignibou-server/build/libs/bignibou-server.jar
env:
APPLICATION_GOOGLE_API_KEY: *******************
- name: bignibou-batch
path: bignibou-batch/build/libs/bignibou-batch.jar
no-hostname: true
no-route: true
env:
JAVA_OPTS: -Dspring.batch.job.names=messagesDigestMailingJob
edit: When I try to set the location of the java buildpack as follows:
cf run-task bignibou-batch "$PWD/.java-buildpack/open_jdk_jre/bin/java -jar bignibou-batch/build/libs/bignibou-batch.jar"
The $PWD
variable is resolved on my local machine before the command is sent...
In general, we consider the location of the installed JRE, as well as the command required to run the application, an internal detail subject to change without compatibility restrictions. To the best of my knowledge (running the Java Buildpack team for nearly four years) there are no contractual obligations requiring droplets to be mounted at
/home/vcap
either, which is why we're very careful to use$PWD
in our commands.Other early users of Java-based tasks have allowed staging to happen completely (which would ensure that things like memory calculation and
JAVA_OPTS
are properly placed in the command) and then use that command line without modification.The issue you're seeing with
$PWD
being resolved early is one of escaping more than anything else. The first change you should probably make is to switch from double quotes ("
) to single quotes ('
) which should ensure that$
isn't resolved immediately. It's possible that somewhere else in the pipeline the environment is resolved again early possibly necessitating a\$
escape, but I'd hold off on that until you're sure that you're seeng it.