Preparing to Repair Gradle's Malformed Module Main-Class Command Line

[Alex Buckley]

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»
> 
> ----
>