Remove BuildTargetKind ?

It’s currently defined as:

object BuildTargetKind {
  final val Library = 1
  final val Test = 2
  final val App = 3
  final val IntegrationTest = 4
  final val Bench = 5
}

Most build tools do not require the user to classify their projects in such a way, so the best a build tool could do is try to guess using heuristics, but that can also be done by the IDE itself. Moreover, this information is only needed to display something nice to the user, not to compute anything, so there really isn’t any reason to keep it in the protocol in my opinion.

[jvican]

Target kinds are useful for clients that want to highlight the nature of a project; for example, an IDE that knows how to run benchmarks can use the Bench target kind to auto-detect benchmarks and allow users to run them from the IDE.

Most of the build tools (sbt, bazel, pants, maven, gradle) have the ability to define targets that are either binaries, library, tests, benchmarks or integration tests; though they do it in different ways.

In Bazel and pants, users define the purpose of a target by choosing the right directive (scala_binary, scala_library, etc). In sbt, maven and gradle, the definition is implicit via the use of Maven configurations (for example, in sbt you add the IntegrationTest configuration to a project that defines integration tests, and likewise for Bench). If a build tool does not know the nature of a build target, it can safely use App as the default.

All in all, the build tool picks the target kind not by heuristics, but by information given by the user.This information cannot be derived from the IDE and it’s therefore required in the project.

See discussion in https://github.com/scalacenter/bsp/issues/12, https://github.com/scalacenter/bsp/commit/80e45b4981fedb86f063b9b07406f3154adc0896 and https://github.com/scalacenter/bsp/pull/5.

[jvican]

Status quo: Pants tries to map target to intellij module one to one. However, if a directory contains multiple targets, intellij-pants-plugin is packing all them into one module, thus causing unintended behaviors in IntelliJ sometimes. E.g. a resources target and a library target live in the same dir.

This logic will then needed to be done on the IntelliJ side /cc @jastice The protocol will allow you to express this as independent targets. I know there are some efforts on the IntelliJ side to update their project model to work around all of these issues, Justin can talk more about that.