Add extra_jvm_options for jvm_binary
#5868
Comments
|
A question was raised as to whether this should use a strategy similar to #6065 ... my feeling is that it maybe should not, and should let people use their own options. The reason for that is that unlike compiler options, jvm options (and jvm properties) can be very specific to binaries/services (although some like memory settings aren't). Additionally, the jvm_options only affect runtime for the application, so "weird" JVM options aren't a hinderance to evolution/consistency of the code like compiler options would be. @benjyw : Does that sound reasonable to you? |
|
Absolutely. There is an important distinction, even in implementation, between "running a JVM because a tool happens to be written in a JVM language" (e.g., ivy, zinc, antlr) and "running a JVM at the explicit request of a user." For example, the former can be nailgunned, the latter not. So, as you say, compiler options are build configuration, but these are pretty much just passthru args. |
|
I have made a fist attempt at this ☝️ ☝️ |
### Problem Targets could not include custom jvm options to be passed to the `jvm_run` task. This creates the need of wrapper scripts around calls to `./pants run ...` Closes issue: #5868 ### Solution The `jvm_binary.py` target now accepts `extra_jvm_options` as a parameter. The `jvm_run.py` task now injects those options into the run command. ### Result Users can now specify `extra_jvm_options` for `jvm_binary` targets.
Similar to
extra_jvm_optionsonjunit_tests, we should supportextra_jvm_optionsonjvm_binarytargets.This would help to avoid wrapper scripts around
./pants runcalls in many simple cases.The text was updated successfully, but these errors were encountered: