Hello,
I’ve just published sbt-nosbt
: an sbt plugin that makes it possible to move full contents of build.sbt
into plain Scala files. The plugin also proposes a nice convention for defining large, hierarchical project structures.
Cheers!
Hello,
I’ve just published sbt-nosbt
: an sbt plugin that makes it possible to move full contents of build.sbt
into plain Scala files. The plugin also proposes a nice convention for defining large, hierarchical project structures.
Cheers!
Interesting. I can’t help but wonder why the sbt team didn’t do that from the start.
They actually did. Before sbt
0.13, it was possible to define your build in project/Build.scala
. Later they removed that feature.
Here’s some rationale: sbt Reference Manual — Migrating from sbt 0.13.x
Similarly, sbt 0.13’s introduction of multi-project
build.sbt
made theBuild
trait redundant. In addition, the auto plugin feature that’s now standard in sbt 0.13 enabled automatic sorting of plugin settings and auto import feature, but it madeBuild.scala
more difficult to maintain.
Folks who prefer to work in plain Scala should also take a look at Mill – there are tradeoffs with sbt, and it isn’t to every taste (I mostly go with sbt), but it’s a nicely full-featured, low-magic build system for Scala.
Are we to understand that nosbt
is also not an acronym, or does it mean “newly organized simply built tool”?
This is a brave and necessary effort!
The one line I must always cut/paste is the setting of scalaHome
for testing my local Scala repo. I never considered a local plugin just to automate that. (I wouldn’t forget the name of my plugin, right?)