Open retronym opened 3 years ago
I've been using IntelliJ (including JUnit tests) in this mode for a few months and it's overall working well.
I had to start sbt in a terminal before doing an import / build refresh in IntelliJ, at least in the past, maybe that's fixed now.
I think the main drawback is the long delay until the IDE is ready when the build changes (common when switching branches - not switching betweeen 2.12 and 2.13, but even switching between 2.13 branches). And losing code-assist in the build itself.
Sorry if this message is redundant, but if you can use bloop instead of the sbt server you should still get code-assist in the build.
Sorry if this message is redundant, but if you can use bloop instead of the sbt server you should still get code-assist in the build.
I'm working on adding to SBT's BSP server too. WIP: https://github.com/retronym/sbt/pull/3
I think the main drawback is the long delay until the IDE is ready when the build changes
I think the problem here is that evaluating bench / Jmh / bspBuildTargetSourcesItem
actually runs JMH source code generator. This is what triggers compilation of library
. IntelliJ would be perfectly happy knowing that bench/target/scala-2.13/src_managed
will be a root directory for generated sources, but the BSP server instead eagerly generates the sources and provides the full list of them.
I guess it does this so that builds the directly override the behaviour of managedSources
are correctly represented, rather than relying on the convention that they should only return files within one of managedSourceDirectories
. I guess for many types of generated sources the user wants them eagerly generated so they can code against the APIs. I feel like this should be a separate BSP operation though that isn't on the critical path to getting the project loaded.
We could probably override:
bspBuildTargetSourcesItem := {
val id = bspTargetIdentifier.value
val dirs = unmanagedSourceDirectories.value
val managed = managedSources.value
val items = (dirs.toVector map { dir =>
SourceItem(dir.toURI, SourceItemKind.Directory, generated = false)
}) ++
(managed.toVector map { x =>
SourceItem(x.toURI, SourceItemKind.File, generated = true)
})
SourcesItem(id, items)
}
In the scala build to be:
val dirs = unmanagedSourceDirectories.value ++ managedSourceDirectories.value
val items = (dirs.toVector map { dir =>
SourceItem(dir.toURI, SourceItemKind.Directory, generated = false)
})
SourcesItem(id, items)
Or, we might be able to tag the bench / Jmh
scope with the no-ide
tag so it isn't imported at all. We should still be able to edit the code.
I've just noticed another problem: the "Refresh All BSP Targets" action doesn't pick up changes to the build definitions that occurred during the lifetime of the BSP server process: https://youtrack.jetbrains.com/issue/SCL-19230 [fixed]
On current 2.13.x, importing / refreshing the BSP build still trigger compilation of the compiler (and library, reflect). I managed to narrow it down to the buildTarget/resources
call, which runs bspBuildTargetResources file:/Users/luc/scala/scala13/#repl/Compile [... a lot more ...]
in sbt. The contender is bspBuildTargetResources file:/Users/luc/scala/scala13/#scaladoc/Compile
, it can be reproduced by just calling scaladoc/resources
in sbt, which triggers compiler/compile
.
I'm out of time for today, but it should hopefully be an easy fix.
updated the issue description with a list of remaining issues
https://youtrack.jetbrains.com/issue/SCL-19300 has been fixed in the meantime
Remaining issues:
IntelliJ could never correctly import our project as a standard SBT project. IIRC that was due to an assumption that scala-library was a third party dependency, whereas in our project we have it as an internal sub-project.
Instead, we have some custom SBT tasks that fill in template IntelliJ config from
./src/intellij/*.SAMPLE
and combine it with result of theupdate
task to fill in the classpath.SBT 1.4.x introduced support for the Build Server Protocol (BSP), which is an alternative means to import the project structure into IntelliJ (or Metals, VSCode, ...).
We should try to migrate to this as the standard way to use our project in an IDE of the users choice.
Status
sbt
once to generate./bsp/sbt.json
The import was successful for me. In the SBT shell I left running, I saw a notification that a new client has connected.
Here's what I saw in the
Build->Sync
output in IntelliJ:Notes: