Asking for your feedback on sbt + Scala Center announcement

Tooling
21

I wrote up sbt 1.0 roadmap and beta-1 post. Please check it out.

Also we pushed out sbt 1.0.0-M5 today, which is the first beta released.

We’d be happy to get your feedback on the sbt 1.0 roadmap on this thread.

1 Like
22

I second that. CBT equally encourages lots of well-defined small modules and like everyone else is equally affected by zincs overhead.

1 Like
23

I thought that ship sailed long ago? .value is a macro, alternatives are deprecated in 0.13 and dropped in 1.0. Same for using .scala over build.sbt. Or do I miss something?

Would you be fine with creating a new JAR replacing the old one? I’m not sure there’s another way to “slightly modify a JAR”—at least not when using JarOutputStream. I guess input libraries are loaded through ClassLoaders, so this change would presumably require more classloader invalidation… though it might well work.

Either way: such an idea, if it makes sense, would probably require its own issue in the SBT tracker.

24

Yea, it would be a new jar rather than a mutation of an old jar. I meant “slightly modified” in the sense that rather than choosing to invalidate everything that depends on a jar when it changes, you would invalidate based on the fingerprints of classes inside the jar.

25

Great news.

I would like to see https://github.com/sbt/sbt/issues/2310 move forward. I assume @sjrd has some input for this as well.

As a community we should have a standard sbt build setup, which people can use to start their projects. This should IMHO contain the following:

  • multiple projects
  • cross version build
  • documentation how to use and comments in the build.sbt
1 Like
26

Another feature I miss with sbt (or maybe just haven’t found yet) is being able to share a bill of materials (BOM for short). This is a common pattern in the maven community (see https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html).
The idea is that projects provide a configuration (pom.xml), which explicitly manages the versions which a certain library depends on. This bill of materials can then be used by the project which uses the library.

For example my project ScalaWebTest depends on ScalaTest, Selenium and HtmlUnit. Chances are the project using ScalaWebTest already has a transitive dependency on HtmlUnit. In this case it is important for me, that I have an easy way to tell my users, which dependency versions should be managed in his project. For maven users, I can do this by providing a bill of materials. See http://www.scalawebtest.org/download.html#maven

27

I suggest to make use of the Dreyfus model when improving the SBT documentation. The Dreyfus model shows how people have different needs depending on their level of a mastering a skill. “Pragmatic thinking and learing” by Andy Hunt (https://pragprog.com/book/ahptl/pragmatic-thinking-and-learning - see chapter 2 Journey from Novice to Expert) puts this in to perspective of teaching IT skills.

(for those wondering about the multiple posts - max. 2 links for new user :frowning:)

3 Likes
28

oh, the other huge thing (sbt 1.0+ or a 0.14 on scala 2.12) would be to use NIO everywhere. So many performance benefits if used correctly, especially on Windows and no more FS polling.

3 Likes
29

Hello @jvican .

For my Scala Projects i currently use Gradle Wrapper with the Scala Plugin.

Now i decide to use sbt.

Some starting points I missed from my point of view:

  1. sbt installation and first start / load of sbt with a Company Artifactory: Here I would like to define the Company Artifactory a) for first sbt start and b) for Project Dependencies (this is already documented : How can I do that ?

  2. I missed a minimal valid .gitignore Definition for a sbt Project (single and multi build). I been confused about the Details in the ‘project’ Subdirectory and it’s content.

  3. Compare the Gradle Wrapper with sbt: Does work the local installed sbt ‘same prinzip’ as the Gradle Wrapper?

As a sbt Beginner
Röbi

1 Like
30

Resolution of this issue would be most welcome:

31

I have been converting a multiproject Ant build to a multiproject Sbt build.

Recently the release for Sbt for Linux on Ubuntu was broken for some time. In my mixed build environment I had BuildBot for CS/CI and Sbt for build and package. My MacOS build machines were up and running but my Ubuntu machines were left sidelined without a functioning Sbt release. References to Java9 had escaped in the packages available to me. From last January, 2017 until just recently, there has no sbt build that I downloaded, that would correct the problem.

I ponder the fact that I am migrating from Ant to Sbt as my build tool, and the Build Tool itself is not being managed successfully. The recovery from the broken release was not RESPONSIVE.

32

What version of Ubuntu are you using? How did you install sbt? Which version of sbt are you using?

sbt 0.13.13 installed via apt from http://dl.bintray.com/sbt/debian/ on a Kubuntu 16.10 works like a charm for me.

33

I have been converting a multi-project Ant build to a multi-project Sbt build.

First off, the size of the build file is reduced. Classpath management is very transparent compared with Ant.

Task execution is so much easier in Sbt. Compile is part of the Sbt DSL.In Ant the tedium of the markup and the amount of boilerplate required make Sbt the clear winner

Migrating Junit tests wasn’t as easy as one would expect. Not due to Sbt, but due to FixedOrder annotations having no effect. My solution was brute force, run each test separately. The command for the BuildBot worker to execute becomes simply, sbt < sbt.cmds. Don’t fight it, run your sbt from a file of commands.

Overall, I am pleased with Sbt.

34

It is not a problem for me now. This was a known issue, I discovered other mentioning it.

35

I now have a 6 host build farm and Sbt is the build mechanism.

36

I’m not hacking the SBT internals or a plugin myself, but seems like sbt needs to support a better integration test framework than scripted. Might the rework in 1.0 and server both benefit and make possible a richer test framework? A framework that would be less tricky but also more performant. This would seem like a sound investment for the plugin ecosystem as well as the sbt core.

3 Likes
37

I’ve suggested putting effort on a better test framework. Seems like now is a good time given the 1.0 and server development.

38

I agree with @fommil; The most important thing for sbt is migration to Scala 2.12 (or Scala 2.11). As we will be late for supporting the latest version of Scala, the more sbt plugin authors will lose the opportunity to migrate their sbt plugins, because we will forget about the implementation details as time goes. Cross-compilation with Scala 2.10 is an option, but I think it’s acceptable even if sbt only supports Scala 2.12, since we are already bearing with sbt that can only use Scala 2.10 plugins.

Another thing I need to see the improvement is reloading time of project configurations; when I modify a library dependency, it usually takes 30 sec or more until my IDE (e.g., IntelliJ IDEA) can start re-configure the project because it needs to wait for the completion of sbt reload task. sbt-coursier plugin helps improving the download speed of dependencies, but this long turn-around time of sbt makes difficult to configure projects.

2 Likes
39

I can’t stand the new feature in 0.13.15 that throws up warnings if you want to run SBT without keeping that VM around permanently. I’m not aware of any other build tool that won’t let you execute a build from the command line without a mandatory, permanently enabled warning that you should start up the build system in daemon mode instead.

I understand that you want to nudge people toward running the console to avoid the extra costs of spinning up a JVM. IMHO, the current mechanism is a repeated, aggressive shove and not a nudge. Putting message like this in the docs, or showing this message once the very first time you use sbt on a machine would be reasonable. Showing it every single time with no configuration option to disable it will ensure that I stay on 0.13.13.

6 Likes
40

My main pain points with SBT

  • Underlying SBT model of scopes/configs/settings/tasks seems to be overly complex and abstract
  • Many of these concepts also tend to be replacements of Scala’s already existing language features (i.e. why have Settings when we can use plain val, why are we dealing with initialization order when we already have lazy in place). Why do we have Task when Scala already has an existing construct (i.e. def)
  • Its incredibly difficult (as an external contributor) to try and contribute to SBT because the design is so complicated
  • SBT has created what is a considered a mistake/abomination in most other language communities, which is some pseudo version of the language which isn’t really the language. In SBT’s case, build scripts are written in an (almost) copy of legitimate Scala code, however in an attempt to “simplify” things there is now a huge amount of magic in how settings are loaded in .sbt scripts
  • The design seems to have not been thought off from scratch, instead it seems to have sought of been based off maven/ivy (a lot of design for stuff like config is based off how maven does things)
  • SBT’s design also means that if you do something that slightly falls outside of what SBT provides, you need hacks like sbt-doge to do non trivial builds (i.e. support Scala 2.12 in a multi project setup, but not for each submodule since not all submodules support 2.12)
  • As a build tool, SBT’s design causes it to use huge amounts of memory (and sometimes CPU). May not be a problem when working on a monolith, but definitely an issue if you are working on modular projects
  • I don’t really see what a purely immutable model with a very convoluted way of creating copies of this immutable representation has brought any tangible benefits. Build tools are all about mutation and state change, it might have been a better idea to use a more mutable model with well thought out API?
  • Features such as runtime adjustments of settings are questionable, its very arguable that the proper way to address this is to have fast iteration cycle (i.e. change source code -> reload project -> run command). This is how CBT solves the problem
  • Performance/usability of SBT in general has issues
    • Although SBT may have high throughput (not sure if this is true?), its pretty irrelevant for most cases due to incremental compilation. I also don’t think that running tasks in parallel provides that much performance improvement, especially with the Scala compiler being as taxing as it is
  • The startup time for most trivial projects in SBT is pretty atrocious, and it also isn’t designed with usability in mind (i.e. SBT has to check all dependencies of your project when it loads, even though its not required a lot of the time, i.e. if you want to run in Scalafmt)
  • Also hard to integrate SBT’s current design in CI servers due to its high load time
  • Resolution with Ivy is really slow, coursier is fixing this but I would rather they make coursier the default resolution mechanism. If it breaks with some weird maven/ivy set up repos, then SBT should claim that it doesn’t support these sought of repo types by default. User experience for 95% of users shouldn’t be hindered because of some really weird repo setups
  • The above also makes developing SBT plugins a real pain, especially with regards to how settings and tasks are defined
  • In general, SBT seems to be good for very trivial builds (i.e. just libraryDependencies and some set versions) or incredibly complex builds usually created by authors who understand sbt very well (i.e. https://github.com/scala-android/sbt-android), but for the middle ground (where most users fall) it falls short in many areas
  • This is also in mind that a build tool is something that every user needs to understand (at some level) because they are exposed to it in every day in life. Its almost always a better idea to keep things simple at the cost of being less expressive or less capable
  • Sticking to Scala 2.10 for so long has probably done a lot more damage than good, especially when taking into account things like macros and reflect
  • Other quality of life improvements
  • SBT doesn’t provide sensible defaults for compiler flags (which are also only exposed as strings instead of proper enums). i.e. if you are publishing, it makes sense to use -Yclosure-elim if you happen to be using 2.11 but if you are using 2.12 then opt:l:project makes sense. Having default flags for the current project with the current Scala version context in mind would prevent needing stuff like https://github.com/knutwalker/sbt-knutwalker
  • Plugins like sbt-mima should probably be included in core sbt as a module (these are pretty much required for any type of sane library)
  • SBT documentation appears to have been written for someone who already understands SBT instead of someone who is completely new to SBT. Not sure how much of this is an issue due to SBT’s already complex design (i.e. its very difficult to do non trivial stuff in SBT without understanding the underlying model which is very complex in design)

At the risk of sounding sensationalist, at least where I work SBT has gotten so bad that coworkers have either given up working on it (which usually means the SBT related work gets delegated to someone who has some SBT experience) or they do stuff like copy and paste code around which creates entirely different set of problems. I haven’t really seen this kind of problem with other build tools. Its gotten bad enough, that even for fairly simple use cases (such as a code formatter) have resorted to using SBT for only its interface, i.e. see http://scalameta.org/scalafmt/#sbt

I don’t really have high hopes of SBT fixing the issues I have described because they appear to be very fundamental, in fact CTB seems to address almost all of the issues. I do like the approach of modularizing SBT more, because at least it makes it much easier for alternative build tools to arise and fix said problems.

4 Likes