-D (aka Java/system property) argument support in "launch" broken?

Coursier 2.0.0-RC5-6

coursier launch --help mentions

  --property | -D  <key=value>
        Set Java properties before launching the app

but it looks like it’s broken?

13:49:18 ! coursier launch scala -Dscala.color -Dfoo=bar
Unrecognized argument: -Dscala.color
Unrecognized argument: -Dfoo=bar

Looks like -J-D works, as a workaround:

13:49:23 ! coursier launch scala -J-Dscala.color -J-Dfoo=bar
Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 11.0.1).
Type in expressions for evaluation. Or try :help.

scala> sys.props.contains("foo")
res0: Boolean = true

scala> sys.props.contains("scala.color")
res1: Boolean = true

[alexarchambault]

I see you used --java-opt in https://github.com/dwijnand/scala-runners/commit/7db0961b3786a6bdc2e5da980a193fe9e48aa337, which should be the way to go.

-J is indended (for now at least) for options for running coursier itself, not for the apps it launches. Things like -J-Dhttps.proxyUser=… can be used to configure a proxy to download things for example.

We could add support for handling -D options (to be used by coursier itself in a first time say), and then ensure the -D / -J-D options are also passed to the launched apps.

Direct support for -D options would break things like --java-opt -Dfoo=bar though, as the -Dfoo=bar would be parsed and removed from the arg list early.

Passing -J-D options to the launched apps from the coursier JVM-based launcher might be tricky too, as we would have to tweak the shell preamble specifically for coursier. This also wouldn’t work on Windows, for the JVM-based launcher.

[dwijnand]

OK, thanks for the pointers! I’d definitely want to add it to both.

Btw, exciting news about the native launchers! I was speaking to @eatkins about those, recently, as he’s been working on a real thin client for sbt’s server, and launcher capabilities too.

I guess I’ll wait for you to push your code up? Could you try to remember to ping me here, when that’s done? I don’t watch this repo. Also: no immediate rush from me on this, I just happened to notice that my scala wrappers in scala-runners behaved differently here to the original scala distribution runners.