I think you mean buildTarget/sources rather than buildTarget/dependencySources here, rigth?

The protocol already allows to send/receive source directories rather than individual files. So technically, a build server can respond with the base directory of the generated sources and trigger the generation asynchronously or even postpone the generation for when it's really needed (buildTarget/compile).

That's not how it is implemented today in sbt, but maybe we should. @jastice Would that work in IntelliJ if the source generation is postponed to the first buildTarget/compile?

Yep, I've update description with the correct target.

IntelliJ's project model only supports source directories so it would be just as happy to receive managed source directories.

Another advantage of this approach that it makes it possible to import a project that has some erroneous code that would prevent the source generators from completing.

But leaving the source generation until the first compile isn't ideal because a) the user can't see / program against the generated APIs until that point.

In sbt we could implement something like this:

case r if r.method == "buildTarget/sources" =>
  val target = ...
  callback.appendExec(s"bspBuildTargetSources $target", Some(r.id))
  callback.appendExec(s"$target / managedSources", None) // trigger the source generations after responding

That would prevent the build import from failing if the source generation fails. But it does not make the overall import time better because the next request, buildTarget/dependenycSources, will have to wait for the source generation to finish.

Actually I think it's not so bad to postpone the source generation until buildTarget/compile. It's true that the user wants to see the generated APIs as soon as possible, and the solution would be for IntelliJ to send a buildTarget/compile just after the build import:

1. Send workspace/buildTargets
2. Send buildTarget/sources
3. Send buildTarget/dependencySources
4. Send buildTarget/scalacOptions
5. Build imported successfully
6. Send buildTarget/compile to force source generation (and resource generation)

Or even better, we could introduce buildTarget/generateSources and buildTarget/generateResources.

That's not how it is implemented today in sbt, but maybe we should. @jastice Would that work in IntelliJ if the source generation is postponed to the first buildTarget/compile?

Yes, triggering a build after import is feasible and probably not too disruptive. But if the build then generates new source directories that are not already reported by buildTarget/sources we'll have the issue that IntelliJ doesn't acknowledge them as project sources.

Yes, triggering a build after import is feasible and probably not too disruptive. But if the build then generates new source directories that are not already reported by buildTarget/sources we'll have the issue that IntelliJ doesn't acknowledge them as project sources.

Yes but we can report the src_managed directory in buildTarget/sources and fill it afterward on buildTarget/compile.

Yes but we can report the src_managed directory in buildTarget/sources and fill it afterward on buildTarget/compile.

Yes, for the sbt use case this should work well. Other build tools may have a different approach and only report actually generated sources.