sbtでサブプロジェクト毎にクロスビルドするScalaのversionが異なる場合のバッドノウハウ

タイトル長くなりすぎるからやめましたが、本当に話したいこと、話すことは、
「サブプロジェクト毎にクロスビルドするScalaのversionが異なる場合」
だけではなく
「さらにその中にsbt pluginがあってscripted testもしたい場合」
です・・・つらい・・・。
"つらい"、というか、それほど重大な問題でもないのだけど、微妙にかゆいところに手が届かない感じでモヤモヤする・・・

以前こんな会話して


結局、これ書いてる時点でのscalikejdbcは、自分が思いついた方式(Scala2.11でビルドできるサブプロジェクトのみを集めたrootプロジェクトを別につくる)でやってます。


さて、それはいいんですが、scalikejdbcはsbt pluginがあるので、当然ちゃんとテストかくならsbtのscripted test http://eed3si9n.com/ja/testing-sbt-plugins でテスト書きたいわけです。しかし、scripted testをするには、事前にまずpublish localする必要があります。
そして、どのサブプロジェクトをpublish localするのかは、自分で考えなければいけません(scripted test実行時になってみないと、必要な依存ライブラリなんてわからないので。sbt側に全部おまかせするのはたぶん不可能)

あと、ちゃんとテストするなら
「scripted testするsbt plugin自体は現状の最新安定版であるsbt0.13.x系、つまりはScala2.10.xでのみビルドすればいい」
ですが、
「scripted test内で使うライブラリのバージョンは、できればScala2.10.xと2.11.xと両方やるべき」

ですよね?

だいぶ話がややこしいけれど、ついてきていますか?

さて、つまりscalikejdbcでのscripted testは以下の様な手順になります

  • Scala2.11用のrootでpublish local (2.10用のpublich localが先でもどっちでもいい)
  • Scala2.10用のrootでpublish local
  • scripted test実行

https://github.com/scalikejdbc/scalikejdbc/commit/12492515881916e7abadd0e5abe88000535d6d6f#diff-f9a62833538ab14fff849c2be16ab986R6

これでできるはずです。
それで、ここで話が前後するというか、飛びますが
「Scala2.11用のrootを作る」
方法が、2通りあることに気づきました。

なんだかどっちもどっちな感ありますね。ただ、前者の「明示的に全部列挙」の方法でやってたお陰で(?)、このコミット

https://github.com/scalikejdbc/scalikejdbc/commit/41125cbfdff02

のときに、本当はaggregateの部分に追加すべきだったのを、誰も気づかなかったですね・・・。
https://github.com/scalikejdbc/scalikejdbc/issues/240#issuecomment-41916945
そのときはscripted testがあったわけでもないので、エラーにならなかったし。
気づくの遅れたといっても、それほど重大な問題でもないですが。

なにが言いたいのかよくわからない感じになってきましたが、sbt-release pluginとかでもsbt本体でもなんでもいいけど、もっとこういった複雑なビルドの場合に、少しでも今よりわかりやすく楽に書ける仕組みを、どうにか作れないかな(誰か作ってくれないかな)・・・と思っただけです。

互換性など色々気にして細かいことを頑張ろうとすればするほど、ライブラリ作者は技術的に面白いことだけではなく、こういった地味な努力してビルドファイル頑張って書いたりしないといけないのが現状ですね