Can the bsp4j classes be more lightweight?

[lefou]

Can we get rid of some of the heavy wight transitive dependencies? Can we split the bsp4j artifact?

My motivation is the extensible nature of build tools. Each build tool it designed differently. Where Mill provides Java, Scala, Scala Native and Scala.js support, Maven needs various plugin even to get a Java build started. Yet, when it comes to extensibility, it's not enough to just implement the BSP server support in one central place. Instead, each built tools needs to deal with the fact, that in order to provide a BSP server, it needs to somehow collect multiple parties and orchestrate them to appear as a unique self-aware BSP server.

BSP capabilities need to be provided early in the protocol phase. To fulfil the modularity constraints, it's often wise to keep transitive dependencies of each party / module to a minimum and lightweight.

In Mill, I'd like to support as much BSP extensions as possible, but that means I need to distribute the server implementation over these plugin. Obviously, those modules need to share some common API. The current bsp4j API isn't well suited for that purpose. The bsp4j artifact it currently rather heavyweight, as it come with lots of transitive dependencies like guava and Xtend.

Currently, we mirror already some of these classes in Mill, to avoid to depend on bsp4j in all modules. We especially want to avoid all these libraries end up on the classpath of the build scripts, as some of these dependencies have caused issues in the past. Especially, when versions differ.

Would it be possible, to split up bsp4j in some lightweight Java classes, implementing the building blocks of the protocol, and have the server implementation in a dedicated separate artifact? The server artifact can be as heavy as it needs to be, of course.

[jastice]

I thought Xtend was already on its way out, but maybe @agluszak can elaborate on the status of that.

I don't yet understand the entire problem though, could you elaborate a bit on the design you have in mind?

[lefou]

Imaging an arbitrary Mill module, which provides some language support, for example a fictive mill-rust plugin. To integrate nicely in the BSP server, it may need to provide something to it, e.g. each module (trait RustModule extends mill.scalalib.bsp.BspModule) want to provide some dependencies. It would be nice to use the dedicated classes from bsp4j (RustWorkspaceResult, RustDependency, ...), without forcing the transitive dependencies of bsp4j on the build classpath.

Of course, this mill-rust plugin may also provide some BSP server extension, which will assume the full current bsp4j classpath present. Let's consider this the implementation detail not of interest here.

My concern is to split the published bsp4j artifact into an artifact with only some Pojos (without dependencies on gson and guava), and one containing the actual server implementation.

[lefou]

What I want is a bsp4j.api and a bsp4j.server artifact. The former has no hevyweight implementation specific transitive dependencies and can be easily used in foreign APIs, e.g. a mill-rust plugin. The latter may contain whatever is needed to launch a BSP server.

[lefou]

• I opened issue Split artifacts into a bsp4j.protocol and a bsp4j.server  #668

[agluszak]

Well, so in general something is apparently configured wrong in the sbt file, because xtend shouldn't be needed at all at runtime. About guava I don't know, I'll check it when I'm back from vacation. But that was my idea too - to separate the json-defining API from the server. But before we do that I'd prefer to finish the migration to bazel.

[lefou]

@agluszak Could you please re-check, whether we could prioritize the split? I have no idea how to contribute it by myself since I have no experience with bazel. Also, the bazel migration is still not finished.

[lefou]

@agluszak Maybe, I misunderstood you, but I though this issue should be fixed rather soon. Now, the bazel migration is done for some time, but I didn't receive any comments on #668.

[agluszak]

Ah, sorry, we now have a busy time at JB. I'll try to handle it next week, okay?

[agluszak]

Didn't manage to find time to do that this week and since next week I'm on vacation, perhaps it's best if I write instructions for you and you do it yourself. You don't need to have experience with bazel to do it.

1. Each library (bsp4s, bsp4j and also bsp4kt, bsp4rs and bsp4ts - which are not in this repository) has a corresponding generator which loads the smithy definition and emits source code in the respective language. In your case it will be easiest if you just copy the bsp4j generator and start removing things. See https://github.com/build-server-protocol/build-server-protocol/blob/master/codegen/src/main/kotlin/bsp/codegen/bsp4j/JavaRenderer.kt and https://github.com/build-server-protocol/build-server-protocol/blob/master/codegen/src/main/kotlin/bsp/codegen/bsp4j/Main.kt
2. Then you'll have to define the generator binary here: https://github.com/build-server-protocol/build-server-protocol/blob/master/codegen/BUILD
   It will look something like this:

kt_jvm_library(
    name = "bsp4j-lite",
    srcs = glob(["src/main/kotlin/bsp/codegen/bsp4j-lite/**/*.kt"]),
    visibility = ["//visibility:public"],
    deps = [
        "@//codegen",
        "@maven//:org_eclipse_xtend_org_eclipse_xtend_core",
        "@maven//:org_eclipse_xtend_org_eclipse_xtend_lib",
        "@maven//:org_eclipse_xtext_org_eclipse_xtext_xbase_lib",
    ],
)

(assuming that you still want to use xtend and write it in kotlin, like the current bsp4j generator).
3. Then you have to register the generator here https://github.com/build-server-protocol/build-server-protocol/blob/master/BUILD

java_binary(
    name = "bsp4j-lite-generator",
    main_class = "bsp.codegen.bsp4j.lite.Main",
    visibility = ["//visibility:public"],
    runtime_deps = [
        "//codegen:bsp4j-lite",
    ],
)

4. Then you'll need to create a bsp4j-lite top level folder and put there a build file like this one:

load("@bazel_sonatype//:defs.bzl", "sonatype_java_export")
load("//:version.bzl", "BSP_VERSION")
load("//tools/rules/generator:generator.bzl", "library_generator")

library_generator(
    name = "generate-bsp4j-lite",
    gen_tool = "//:bsp4j-lite-generator",
    out_dir = "src",
    visibility = ["//visibility:public"],
)

sonatype_java_export(
    name = "bsp4j-lite",
    srcs = glob(["src/**/*.java"]),
    data = [
        ":generate-bsp4j-lite",
    ],
    maven_coordinates = "ch.epfl.scala:bsp4j-lite:%s" % BSP_VERSION,
    maven_profile = "ch.epfl.scala",
    pom_template = "//tools/maven:pom.tpl",
    visibility = ["//visibility:public"],
)

5. Now you'll be able to generate the library by running bazel run //bsp4j-lite:generate-bsp4j-lite (well, assuming you have bazel on your machine, ofc).

Cc @jastice @abrams27