今日の流れ

sbt server reboot

single JVM process
implemented as a command, sort of
JSON API to drive sbt from network
forkingを行って裏でsbtサーバが走る→サーバを探すのが面倒
コマンドとしてsbtのサーバを実装することにした
サーバのプロセス→JSONを使って外部からネットワーク越しに起動する
IDEとの統合/分散ビルドの点でうれしい
エコシステムにおける役割分担
sbtの作者というよりはLightbend社員としてやっており、ビルドツールのどれかが隆盛してくれたらいいし、Scalaを盛り上げるのが目的
- IDEからsbt serverできたほうがよい
- distributed build 分散してビルドできたほうが良い
- 0秒コンパイルの仕組みを作りたい
今あるサーバはマルチクライアントシングルサーバ
2つのクライアントをサポートする仕組み

sbt server
serverPortでポートを設定できる
telnet 127.0.0.1 5173
- channelName: channel-1を含むJSONデータが返ってくる
- 人間がタイプするのをJSONに置き換える
エンドユーザーから見るとJSONを直接ごにょごにょすることはない
sbt client(仮)
- sbt client 127.0.0.1:5173
- 将来的に2つのsbtプロセスに分けたほうがいいかも
- 分けないとシンプルになるけどユーザーが自分で立ち上げないといけない
- thinクライアントがあって、別のプロセスでサーバを立ち上げるようにしたい
コンパイルの作業
- compileタスクの入力はソース、出力はファイルと画面表示
- return typeなんて使わなくって、クラスファイルとか出てくるwarningとかをユーザーは知りたい
testを打ち込むとOK/NGを返してくれる
だいたいのタスクの出力はディスクと画面への副作用
- それをネットワークに抽象化するにはsemantic logging/event loggingをつかう
- 直接stringを送るのではなく、疑似case classを送ることでうまいこと処理できるんじゃないか
ログでアウトプットするのが変わってくるのではないか

sbt1になったときに詰め込みすぎると不安定になるので、13シリーズにあるだけ詰め込んでテストしたい
sbt1への移行は小さく
13.6
- name hashing
- https by default
13.7
- natural whitespace handling
- cached resolution
13.8
- cross-version
- sequential tasks 逐次タスク
- maven resolver
13.11
- dotty support
- configurable compiler bridge
- inter-project dependency tracking
- sbt はscala 2.10
- 簡単に言うとsbtはJavaをアセンブリぽく使う
- Scalaのバージョンは関係なくコンパイルできる
- dottyのbridgeを書く
13.12
- deprecates project/Build.scala(なんでやったの? build.sbtでぜんぶできるから。2つ残すとめんどくさいからbuild.sbtだけを残した)
- scalaVersion enforcement
13.13
- sbt new
- synthetic subprojects プロジェクトから子プロジェクトを派生→開発環境を作るときに裏でDBを走らせるみたいなことをプラグインからできる
- <<=/<+=/<++=を廃止勧告
13.14
- Java 9 compatibility bashのほうでやるかもしれない bash/jarを組み込むことでjava9が動く
- Other bug fixes

プラグイン環境を作るにはバイナリ互換性が重要
- 裏を変えずにごにょごにょできるから
- メンテするのがしんどいのがデメリット
- コードが汚くなっていくのもつらい
- バグの温床メンテが難しい
incremental compiler
dependency
ほぼ全部の機能が新しく入れ替わるので新陳代謝が激しい=諸行無常

less is more
少なめにやったほうが安定性が高い
いらない機能はどんどん捨てていく(bridgeとか)
scala 2.9もコンパイルできなくする
途中からscala 2.10も捨てるかも
scala 2.12を入れる
諸行無常への対応としてのモジュール化
今のsbtはすべてソースを公開している→バイナリ互換性を保つのがしんどい
ほかの人が直そうとしても直せない
Zinc API/librarymanagement API/IO API
- エコシステムを破壊しないで済む
Zinc API
- Scalaコンパイラを駆動するための統一API
- ほかのツールを作っている人でも使えるようにする
- Zincのみをcontributeできるように
librarymanagement API
- free of Ivy
インパクト
- 短期的には移植コストはあると思う
- 差分コンパイルはZyncで高速化すると思う(5-10倍)
- 長期的にはツール環境が良くなる
プラグイン作者
- JSON compatibility
- 使っているプラグインによってはJSONの名前が不変になるかも
課題
- エコシステムの作り直しに伴う検証
- いまあるものでコンパイルできるようにする