I would prefer SBT to give up its DSL and move to plain Scala code. The
only reason I don’t abandon SBT DSL in my projects in favor of a plain
Scala build file is that most docs and examples are written for the DSL,
not plain Scala code, and I still find it difficult to translate.
Also, the SBT docs read something like this: “It looks like simply
assigning values to keys, but don’t be fooled, it is more complicated than
that! That’s why you need to learn about concepts first to understand the
difference!”
And then I read through the concepts and at the end, I still don’t
understand how it is effectively different from simply assigning values to
keys.
One possible solution might be to detect scalac messages prompting users to add a compiler flag and to insert instructions on how to do that from SBT. JIT instructions. When the user is already frustrated because they can’t get their code to compile the last thing we want is additional frustration because they can’t figure out how to act on the compiler feedback.
I’ve been thinking about this thread over the past day and I keep coming back to the same question. Are we as a community sure that this goal is aligned with the Scala Center’s goal of “Substantially grow our community of open source contributors.”? As an open-source contributor who would like to contribute even more SBT has consistently been one of my biggest impediments to contributing further. This feel like asking people what they want and hearing a faster horse. Sure, if you pool a group of scala developers who use SBT and ask, do you need help using SBT to do basic tasks you will hear 80% of them say “Yes, please help me” but I would love for the Scala-Center to take a longer term view and ask if 80% of experienced scala developers cannot accomplish their goals with a tool, maybe we need more than improving it’s compilation time?
If your problem is
Sub-par performance.
Learning and using sbt is difficult.
Lack of community involvement.
And it consistently resolves around SBT, then maybe more SBT is not the answer. Or at least not in it’s current incarnation. I honestly believe learning how the sausage is made is not going to make more people want to contribute to SBT, or to Scala in general, so I am not trolling here, I just don’t share the belief that educating people on what I see as a failed design experiment in Scala is the best thing we can do to encourage adoption and I would prefer to see a few people take a step back, pretend they had never heard of existing solutions, ask users what they would like to accomplish, and see if they still believe educating them on the design philosophy behind sbt is the correct solution.
I also am not a fan of the idea of the Scala-Center teaching design practices that we as a community no longer support. Do we really want newcomers to learn about using macros and DSLs that don’t behave like regular scala as soon as they pick up Scala. It’s almost polar opposite of teaching Scala - The Simple Parts. I would much rather have Scala-Center teach beginners http://underscore.io/blog/posts/2015/06/25/keeping-scala-simple.html than how macros work.
With regard to Zinc, this all sounds reasonable. The only thing that isn’t explicitly spelled out here is support for fine-grained builds. Folks using Zinc via Pants (and Bazel, presumably) are encouraged to create lots of well-defined, small modules, and to use “strict” (ie, only directly declared) dependencies.
This allows for better cache hit rates against distributed build caches, but requires that Zinc support low overhead per invoke to avoid the actual compilation of ~2000 source modules being dwarfed by the startup overhead.
Finally, achieving incremental compile within jars would be a massive boost as well: ie, compiling directly to output jars, and then supporting incremental compile that consumes the slightly modified jars. The JVM hates classpaths containing loose classes in directories (anecdotally, jarring all inputs improved cold-build performance by 4x in one case due to drastically fewer syscalls and less IO), and this definitely affects Zinc when lots of modules are in play.
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.
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.
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
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 )
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.
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:
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 ?
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.
Compare the Gradle Wrapper with sbt: Does work the local installed sbt ‘same prinzip’ as the Gradle Wrapper?
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.
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.
)