Questions about 1.0

43 views
Skip to first unread message

Edmund Noble

unread,
Apr 15, 2017, 3:38:18 PM4/15/17
to sbt-dev
Hey all! I had a few questions about SBT 1.0, now that the release is approaching fast.

First off, IntelliJ has their own Scala typechecker and their own "use SBT shell for builds" option. I noticed that 1.0 adds SBT server and JSON as the intermediate protocol. What benefit does IntelliJ (and other tools, like ensime) get concretely from these changes?

Secondly, I've heard in many places of SBT 1.0 having big plans for features, but most of them being implemented in the 0.13.x series; what effect has that had on the SBT codebase? Especially in terms of tech debt? Is it perhaps fair to say that this "feature-stealing" has had enough of a profound effect that 1.0 must be a gigantic reorg, and that the amount of organizational changes in 1.0 makes it impractical to add extra features in 1.0?

Thirdly, I'm curious as to whether this "SBT server" project is part of a larger project to make the Scala compiler and associated tooling much easier to access for third-party tools in general.

Thanks!

eugene yokota

unread,
Apr 15, 2017, 4:16:16 PM4/15/17
to sbt...@googlegroups.com

Hi Edmund,

On Sat, Apr 15, 2017 at 3:37 PM, Edmund Noble <edmun...@gmail.com> wrote:
Hey all! I had a few questions about SBT 1.0, now that the release is approaching fast.

First off, IntelliJ has their own Scala typechecker and their own "use SBT shell for builds" option. I noticed that 1.0 adds SBT server and JSON as the intermediate protocol. What benefit does IntelliJ (and other tools, like ensime) get concretely from these changes?

We're sort of laying out the groundwork for better integration.
I'm not sure what immediate improvement we can promise, but here are things that I envision that might be possible in the future.
  • Seamless import. Currently each IDE needs to implement a plugin to inspect the build setup for importing. server makes that a first-class feature of sbt.
  • Retrieving events from common tasks. When we run `compile` or `test` task, often what we care is not the *.class, but actually the string output on terminal window, such as compiler errors and test results. Server exposes these as events that can be picked up.
  • Potential plugin integration. sbt has a rich ecosystem of plugins from code formatting to deploying to cloud. Plugins could start to expose JSON events such that IDEs can add UIs to perform these actions.
Secondly, I've heard in many places of SBT 1.0 having big plans for features, but most of them being implemented in the 0.13.x series; what effect has that had on the SBT codebase? Especially in terms of tech debt? Is it perhaps fair to say that this "feature-stealing" has had enough of a profound effect that 1.0 must be a gigantic reorg, and that the amount of organizational changes in 1.0 makes it impractical to add extra features in 1.0?

Adding a bunch of new feature to 0.13.x series has had tradeoffs.
  • On the plus side, we get shorter feedback cycle to experiment features on existing builds and fix them.
  • Also on the plus side, keeping 0.13 stable allowed plugin ecosystem to grow.
  • On the minus side, keeping binary compatibility with 0.13.0 resulted in duplicate code and occasionally weird tricks. This is the motivation for avoiding case classes in sbt 1.0 as much as possible.
Thirdly, I'm curious as to whether this "SBT server" project is part of a larger project to make the Scala compiler and associated tooling much easier to access for third-party tools in general.

That's a good insight. As I got more into "server", I'm realizing it's more about semantic logging than about RPC i.e. `compile` vs warning messages. Once it proves its utility, it might be interesting to split out the event/logging aspect into a separate thing.

-eugene

Seth Tisue

unread,
Apr 15, 2017, 8:12:38 PM4/15/17
to sbt-dev
On Sat, Apr 15, 2017 at 2:37 PM, Edmund Noble wrote:

> impractical to add extra features in 1.0?

not sure I understand the thinking behind the question.

are you asking "why aren't there more new features in the initial 1.0
release?" if that's the question, then I think the answer is twofold, one,
a lot already went in 0.13.x, two, at this point the overriding scheduling
concern is to get on Scala 2.12 as soon as possible since that move is now
so long overdue.

if you're asking something more like "will it be hard to add additional
features to future 1.x releases?", that I can't address.

Edmund Noble

unread,
Apr 16, 2017, 2:53:20 AM4/16/17
to sbt-dev
Hey guys,

First off, thanks very much for the replies. I'm very interested by these observations about semantic logging; I think that's a lesson a lot of tools (and even apps) can take home.
Also very glad to hear that some hurdles in 0.13.x development have lead to great improvements in 1.0's architecture, especially sbt-datatype. 
I'd just like to make it clear that I'm really not trying to be snarky or express disappointment at 1.0's featureset - just genuinely curious about the process of SBT's development.

-Edmund
Reply all
Reply to author
Forward
0 new messages