I was going to ask if setting `jvmArgs` in the `run` task is the right
way to configure Gradle, but I see it's done here:
https://guides.gradle.org/building-java-9-modules/#modify_the_code_run_code_task_to_use_modules
Setting aside `-m`: How do you specify the traditional `java -jar
myapp.jar` to the `run` task? If it's by setting `jvmArgs` then
presumably the same problem occurs of stray arguments being passed to
the main class?
BTW your module path doesn't need to spell out the JAR file. Just
`build/libs` is enough for the Java compiler and the Java runtime to
find `my.module`. A module path option should be orders of magnitude
shorter than a class path option!
Alex
On 10/16/2019 3:03 PM, Plugins wrote:
Hi all,
Please review this issue [1]? It reports a defect in the Gradle build
tool's current construction of malformed java command lines that are
intended to execute a Main-Class of a JPMS module.
At first I thought the bug reported there was in either the Dropwizard
application framework I was using at the time, or in the CLI parser
utility (argparse4j) Dropwizard uses under the hood.
I am now convinced — by diagnosis done by those two projects'
maintainers — that the command line construction bug is definitely in
Gradle's court.
I'd like to request from the list you all's take on this. Please? I have
been experimenting with a solution that works so far. But any insight or
suggestions anybody here can offer would be muy appreciado! TIA.
----
[1] http://bit.ly/Issue10825 «Refactor
JvmOptions.getAllImmutableJvmArgs() to support executing the main class
in a JPMS module»
----
