IntelliJ Support

[dwijnand]

I've been using this quite successfully.

I had to workaround #3 by adding adding classpathTypes += "maven-plugin" and I still need to go back and verify #21 is fixed (for me), but it's been great.

However, IntelliJ IDEA uses its own, bundled sbt-launcher. I could override that setting and link it to, for example, ~/.sbt/launchers/coursier_1.2.5/sbt-launch.jar but what happens when I try and import an sbt 0.13 projects? Or maybe a project on a slightly older version of sbt 1? Also I'd probably want to keep using the latest (and greatest) version of coursier's sbt-launcher, so I'd have to update the jar to use (in one way or another).

Would it be possible to do some coordination and collaboration with @jastice of JetBrains to bring coursier's sbt-launcher support to IntelliJ IDEA? Maybe in some experimental capacity. I'm happy to help test the nightlies of IntelliJ Scala.

[jastice]

What does happen if you change the setting in IntelliJ? Wouldn't the this only change the behavior of the launcher itself?

I'm happy to look into this next release cycle (April/May)

[dwijnand]

No, using the coursier sbt-launcher makes all parts of sbt use coursier, for both the build dependencies and the project dependencies.

[jastice]

That's neat. From IntelliJ-side we could have some kind of option to use this launcher when a certain required sbt version is configured, for example.

[dwijnand]

Works for me!

Perhaps @alexarchambault can give provide that info: what versions of sbt would coursier's sbt-launcher work for?

[alexarchambault]

It ought to work back to sbt 0.13.8, the first sbt 0.13 version sbt-coursier was compatible with. (And seems to in a few manual tests, and in the automatically tested project.)

Never tested it with sbt versions prior to that one. The launcher may need to be modified so that it doesn't try to inject sbt-coursier upfront with those.

I don't know in what extent the mainline sbt launcher changed during 0.13.

[alexarchambault]

Intellij seems to be fine using the JAR of the coursier sbt-launcher as sbt JAR. (Although when I try it, the setting seems to revert back to bundled launcher on its own sometimes, I'm not sure why.)

Same by passing the custom sbt-extras script to metals.

[alexarchambault]

@jastice Is there a way to have the launcher, or an sbt plugin, report some progress directly to IntelliJ? It would be nice if the launcher or sbt-coursier could display progress bars in IntelliJ, like those we get when importing a Maven project.

[jastice]

There's always some way, but I'd have to look into how practical it is. Communicaton with sbt is still only by parsing shell output. These days I like to move everything on BSP ;) which has a progress reporting API that I already support. But it would be a bit of work to make sbt support it as well.

[dwijnand]

So I tried out using ~/.sbt/launchers/coursier_1.2.5/sbt-launch.jar as the replacement sbt launcher jar, and IDEA makes use of --addPluginSbtFile which coursier's sbt-launcher interprets for itself, doesn't understand it, then quits. This is why coursier's sbt-extras adds a --.

I've not spent time thinking through the best solution yet. But this is a blocker on being able to use coursier/sbt-launcher in IntelliJ.

[alexarchambault]

It's been working fine from IntelliJ on my side. It seems it relies on ~/.sbt/1.0/plugins/idea.sbt rather than --addPluginSbtFile on my machine.

[alexarchambault]

But the launcher could always be tweaked, so that it doesn't accept options by default (and passes them all to sbt).
And a Java property, set from the sbt-extras launcher say, could optionally enable argument parsing.

[dwijnand]

I think more recent versions of IntelliJ's Scala Plugin use --addPluginSbtFile instead of idea.sbt? Perhaps we should tweak the launcher to just pass through and sbt-extras should add something if coursier_args isn't empty.