Add support for coursier-based sbt launcher (WIP)

[alexarchambault]

Enabled if the environment variable SBTX_COURSIER is set to "true".

I'll look into adding some tests if those changes seems ok to you, @dwijnand (and CI is fine).

[dwijnand]

Mostly looking good, but I want to understand -Dcoursier.sbt-launcher.parse-args=true better first.

And definitely need some tests to verify (and enforce) the desired behaviour.

Thanks for picking this back up, Alex!

[dwijnand]

The "for itself by the coursier-based launcher" is confusing.

And I kind of don't understand how this works. What is -Dcoursier.sbt-launcher.parse-args=true and why is it needed and not the default?

If I understand this properly it means:

• if I specify SBTX_COURSIER=true (which sets coursier_launcher_version to true)
• and also specify a coursier argument, let's say -CshortCircuitSbtMain=true
• then the script will run:

java \
  -Dcoursier.sbt-launcher.parse-args=true \
  -jar ~/.sbt/launchers/coursier_1.2.4/sbt-launch.jar \
  -CshortCircuitSbtMain=true \
  --

Is that right?

[alexarchambault]

Just changed that to

[[ -z "$coursier_launcher_version" ]] || {
  addJava "-Dcoursier.sbt-launcher.parse-args=true"
  addCoursier "--"
}

which should be a bit clearer.

The coursier.sbt-launcher.parse-args Java property tells the launcher to parse itself arguments before a --, rather than passing everything to sbt (we handle the -C… args to it this way).

[dwijnand]

Ok, and why is it opt-in instead of the default behaviour?

And why is the -- required?

Couldn't csbt just always handle -C options (removing them from being passed to xMain) and handle a user-input --? I'm thinking perhaps sbt-extras shouldn't add the -- itself.

[alexarchambault]

That's a good point. I guess the launcher could handle the -C options itself, yes. I'm going to look into that.

Initially, coursier.sbt-launcher.parse-args was added in the context of coursier/sbt-launcher#26 (so that it doesn't try to parse arguments if not asked to do so, and IntelliJ calling it with --addPluginSbtFile … works fine).

[dwijnand]

I think the launcher should handle arg parsing like sbt-extras does: using the equivalent of a residual_args that it forwards on. So when it sees a --addPluginSbtFile it doesn't understand it saves it for forwarding, then moves to the next argument (the argument to --addPluginSbtFile) which it doesn't understand and saves that one too.

As a safeguard, it could handle a -- as an instruction to pass the remaining arguments upstream (it doesn't pass the -- upstream). (Side-thought: maybe it should also handle -C-- also/instead? 😕)

[dwijnand]

Bits and pieces. It's looking better and better for sbt-extras.

We should start thinking about tests for this.

[dwijnand]

Hey @alexarchambault when you get a chance could you comment on how coursier/sbt-extras and coursier/sbt-launcher has been going? I'm more and more keen to switch sbt-extras to coursier's launcher.

[alexarchambault]

Little changed since I opened this PR. I'm using it fine 100% of the time on my machine (for all sbt projects I use, and via IntelliJ and metals too). There might still be a few issues to look at (coursier/sbt-launcher#65, maybe coursier/sbt-launcher#36 too).

I also have to take coursier/sbt-launcher#102 into account too (not as is, I'm thinking of other workarounds to have sbt re-use the test-interface classloader).

[dwijnand]

I've merged master into your coursier branch and pushed that to https://github.com/dwijnand/sbt-extras/tree/coursier, which is the sbt runner I'm using as of the last 2 days.

[sideeffffect]

@dwijnand this doesn't work behind a caching proxy like Nexus or Artifactory, even with -sbt-launch-repo and tweaked

make_coursier_url () {
  local version="$1"
  echo "https://company.com/artifactory/maven/io/get-coursier/sbt-launcher_2.12/$version/sbt-launcher_2.12-$version.jar"
}

fails with

Exception in thread "main" java.lang.NoClassDefFoundError: scala/MatchError
	at coursier.sbtlauncher.MainApp.main(MainApp.scala)
Caused by: java.lang.ClassNotFoundException: scala.MatchError
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 1 more
Process exited with code 1

[dwijnand]

Hmm, I wonder is that a mistake in how the launcher jar was created, or something like that? @alexarchambault?

[sideeffffect]

still failing

[addJava] arg = '-Dsbt.repository.config=/etc/sbt/repositories'
[addJava] arg = '-Dsbt.override.build.repos=true'
[addJava] arg = '-Dsbt.task.timings.on.shutdown=true'
Detected sbt version 1.3.4
Downloading sbt launcher for 1.3.4:
  From  https://company.com/artifactory/maven/io/get-coursier/sbt-launcher_2.12/1.2.18/sbt-launcher_2.12-1.2.18.jar
    To  /root/.sbt/launchers/coursier_1.2.18/sbt-launch.jar

Using default jvm options
Detected Java version: 11
# Executing command line:
java
-Xms512m
-Xss2m
-XX:MaxInlineLevel=18
-XX:+UnlockExperimentalVMOptions
-XX:+UseJVMCICompiler
-Dsbt.repository.config=/etc/sbt/repositories
-Dsbt.override.build.repos=true
-Dsbt.task.timings.on.shutdown=true
-jar
/root/.sbt/launchers/coursier_1.2.18/sbt-launch.jar
check
run

saving stty: 
Exception in thread "main" java.lang.NoClassDefFoundError: scala/MatchError
	at coursier.sbtlauncher.MainApp.main(MainApp.scala)
Caused by: java.lang.ClassNotFoundException: scala.MatchError
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 1 more

[dwijnand]

Btw, I have a branch https://github.com/dwijnand/sbt-extras/tree/coursier where I integrate the changes in master here with the changes in Alex's sbt-extras.