5 drawbacks to liking SBT
I have an opensource project written in scala called testcontainers-scala (if your heart beats faster when you hear docker, be sure to click on the link). Several days ago I received a pull request that adds scala 2.12 support to my project. Sounds great, right? But unfortunately that broke scala 2.11’s compatibility. To solve this issue, there is a quite standard solution in the scala world - Cross-building. I hadn’t had much experience with SBT by that time and I had decided to give a try. In this post I’m going to show you what came of this.
In the comments on Reddit for my article about integration testing in scala, somebody said:
Even though I “use” sbt I wouldn’t exactly say I know to use it. All I do is copy and paste crap for the most part.
I spent two days trying to replicate the functionality of my Gradle script using this “copy and paste crap” approach. I briefly read the official documentation, reviewed a lot of stackoverflow threads and after all I lost hope. Here’s why:
SBT is super slow. Each time I run tests there were several preparation steps that were downloading and checking some random things. Subjectively, everything took at least 1.5 times more time than it took in the Gradle script (especially using the Gradle daemon).
2. Project properties
My gradle script reads properties from file and It’s even a built-in Gradle feature. I have two properties files: a local one that is stored along with the project and a global one located in
~/.gradle. If I want to override some property for a particular run, I can use
-P command line options.
I needed the same in SBT. I googled it - this is what I found.
Really? What do I do if I want to have both a local file for versions and a global one for my private data? What do I do if I want to override it via a command line option? - Code it!
3. Test exclusion
I have two type of tests: unit and integration. Because the code base of the project is really small, I keep all of them in one sourceset
src/test/scala (I know - I know, it’s not a good practice). But I cannot run integration tests every time I start a
test task because Travis-ci doesn’t allow me to run docker in my tests. In my gradle script, I do a simple trick:
It’s very simple and clear. If I had a bigger codebase I could also do:
- Add an extra sourceset
- Create a sub-module
What do we have in SBT? - Tags. Ok, I found some examples here and here. Also, we need to modify a task
test to make it exclude these tests and create a new one which works with only these. Here’s the documentation.
Wait, I’m lost, how to glue all of the pieces together? Where to find the missing ones?
Maybe I can configure an additional sourceset or create a sub-module? - Yes, but you’ll have to read the entire “spaceship manual”.
4. Publishing to maven central
My library should be published to maven central to be accessible by all build tools. I found a documentation - Publishing.
There are two ways to specify credentials for such a repository. The first is to specify them inline: … The second and better way is to load them from a file, for example:
Wait, I thought there are no built-in tools to work with properties files. Oh, that works for credentials only.
I think I can live with that. What next? I need to sign my binaries. So here’s my signing key. Where to put it?
Note: While it is general practice to drop the higher-order bits of 64-bit integer keys when passing ids around, the PGP plugin requires the full key id currently.
Not a problem -
gpg --keyid-format LONG -k
But I want to read my key from the properties file like this
build.sbt:82: error: `value` can only be used within a task or setting macro, such as :=, +=, ++=, Def.task, or Def.setting. usePgpKeyHex(appProperties.value.getProperty("signing.password")) ^ [error] Type error in expression Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
I don’t like to keep complex manual procedures in mind - I automate everything. In Gradle, I have a release plugin. It’s very simple and flexible. What it does:
- Asks what version to release and updates the current version in the project properties
- Tags the current git commit
- Pushes the commits to upstream
- Using gradle task dependencies, builds project, runs tests, uploads archives
That’s it. It can’t be easier. What we have in SBT? - Painless release with SBT
Wait, do I need to write more code than I have in my libriry just to release? I’m not even sure that it can be blended with code I wrote on the previous steps - I don’t even want to try otherwise I’ll have to be debugging it for new two days. Let’s leave it in the old-fashioned way - manually.
After two days I gave up. I didn’t find any features in SBT which I don’t have in Gradle. Afterwards, I implemented cross-building in my gragle scripts. It’s less elegant but works well and doesn’t break all what I had before.
As for SBT, It seems I’m not the only one who struggles with it. I think, a build tool shouldn’t be so complex and counter-intuitive. The lack of good documentation and good examples makes the quick start quite impossible. You can just sit and copy and paste from documentation and have something working in a few hours. All you need to do is dig and pray so that in 10 years you’ll be lucky to get a “Ph.D. in SBT”. The current state of SBT doesn’t look mature, all standard procedures which are built-in to maven or Gradle should be coded by yourself.
So, I’ll stick with Gradle.