-
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. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 7 replies
-
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
What I want is a
bsp4j.api
and absp4j.server
artifact. The former has no hevyweight implementation specific transitive dependencies and can be easily used in foreign APIs, e.g. amill-rust
plugin. The latter may contain whatever is needed to launch a BSP server.