Separate project and dependency sources for a target

Currently buildTarget/dependencySources will deliver both actual project sources / source directories and library dependency sources in one result.

However these are semantically different. Project sources are part of the actual compilation. Library sources are only used for browsing definitions or generating documentation. Editing them has no effect on the compilation output.

In the general case, it’s not possible to differentiate between project sources and library sources based on file/directory type or location. We are currently using heuristics (directory vs jar), but this is not very robust and doesn’t even cover all cases which can already be supported. For instance, in IntelliJ it’s possible to attach any directory as library sources, and the editor will be aware that it is not part of the project sources.

to be discussed for bsp 2.0

[olafurpg]

After discussions with @jvican we came with the following proposal

• remove buildTarget/textDocuments
• bloop should not include project source directories in buildTarget/dependencySources
• add new request endpoint buildTarget/sources

// Request from client to server
trait BuildTargetSourcesParams {
  def targets: List[BuildTargetIdenfitier]
}
// Response from server
trait BuildTargetSourcesResult {
  def items: List[SourcesItem]
}
trait SourcesItem {
  def target: BuildTargetIdentifier
  def sources: List[SourceItem]
}
trait SourceItem {
  /** Represents a directory if the uri ends with a slash /, otherwise a text document */
  def uri: Uri
  def kind: Int
}
object SourceKind {
  val Default = 1
  val AutoGenerated = 2
}

[jvican]

I think it would make sense to add a field sources in BuildTarget given how generic this property is for any target. Then, we can delegate dependencySources to fetch sources of project dependencies only.

I’ve been thinking about merging this spec change with my proposal in https://github.com/scalacenter/bsp/issues/14 so that the demand of sources of project dependencies is always done by the client explicitly and lazily. However, I think that we should still keep this entrypoint for two reasons:

1. Simplifies the life of the client implementations.
2. Some clients may not support this feature at all.

Anyhow, it’s still premature to tell. I’ll get back to this before 2.0.