Once you start to dig deeper, you find out that setting multimodule projects is still easier in SBT. And if you decide to dig deep and really learn the build tool, it doesn't really matter which one you choose. But devs that chose SBT as their Scala build tool will probably keep using it.
The build REPL has lots of commands that aren't documented, and when you search for tutorials the commands have changed (e.g. runMain is apparently now run-main, and if you write runMain you get the wonderfully helpful error "Expected ';'"). There's nothing so simple as Maven's list of phases https://maven.apache.org/guides/introduction/introduction-to... ; instead each project has its own slightly different set of build commands.
> Once you start to dig deeper, you find out that setting multimodule projects is still easier in SBT. And if you decide to dig deep and really learn the build tool, it doesn't really matter which one you choose.
Disagree. Maven multimodule projects are very simple: you can have a module that contains a list of submodules to build and... that's it. Importantly, every submodule acts exactly like a normal top-level project, so if you only ever want to work on one module you don't have to understand anything about the bigger project. And moving between single-module and multi-module projects isn't a big conceptual leap.
SBT multimodule projects are not only their own unique thing, they make the above problem even more confusing, because each project has its own slightly different set of build commands, and each module has a slightly different subset of them that works.
And even if you really learn it in detail, SBT is still awful on multiple levels. https://www.lihaoyi.com/post/SowhatswrongwithSBT.html talks about the deeper problems.
Maven multimodule projects are strange. Yes, modules can work without knowledge of what's above them, but that's not usually what we want to do, because it means lots of duplication (e.g. dependencies) which can then lead to inconsistencies. And if the common settings are defined within the parent project, it stops being self-contained. SBT accepts this reality and that's why multimodule projects are a thing. And having multiple subprojects in SBT doesn't mean that suddenly some of them work and some don't. By default, every project has the same settings (save for the obvious ones, like where the sources are). Any extra settings and task definitions just tell SBT to do extra things when certain tasks are run. One quick example: if you enable the integration test configuration just for some subprojects, the ones that don't have them don't start to fail. They correctly report a "successful, 0 tests run, 0 test failed". By the way: creating a separate integration test config in Maven is painful, up to the point that people recommend to just add a new subproject that contains them. Yay, more nesting!
Regarding SBT current shortcomings: that article correctly points out lots of issues, like the lack of tooling. To this day, IntelliJ still has issues downloading the correct SBT sources. And when they work, there's no easy way to find the actual code that does the work. That should be improved, because for lots of plugins, a quick look at the source is just what's needed when working on the build. Namespacing is a problem too. The internal complexity of the core SBT concepts is complained about too, but that's not as solvable as the other two things.
All in all, Maven and SBT are different tools that focus on different issues, and choose different sides in the consistency vs flexibility tradeoff.
Ah, I got it backwards: old tutorials say to use "run-main", and if you do run-main now you get "Expected ';'".
> There are lots of available commands indeed, due to the nature of SBT, but a basic workflow always uses the same commands: compile, test, run. Any extra tasks used usually come from plugins, just like in Maven. And reading documentation is needed for configuring and running those, just like in Maven.
But in Maven you don't need to read any documentation if you're just building the project, because every project has the exact same lifecycle. If you want to add or remove plugins to make the build do something different then you need to read the documentation of those plugins, sure, but you don't have to know anything about the plugins if you're just working on the code. E.g. if an SBT project is packaged for docker then you'll have to run some docker-plugin-specific command to do it (and you've got no way to discover which submodule you're supposed to run it in), whereas if a maven project is packaged for docker then you just run "mvn deploy" as usual.
> And if the common settings are defined within the parent project, it stops being self-contained. SBT accepts this reality and that's why multimodule projects are a thing.
Parent projects work consistently whether or not you're using a multimodule project, which is another problem with SBT - it's really confusing to share parts of a build definition between more than one project, to the point that most people copy/paste instead. With maven you can do a very natural, gradual progression from single module -> multi-module project -> multi-module project where the parent is its own module -> independent projects using a shared parent (e.g. an organisation-level parent). It's another case of a hierarchy working much better than a grid.
> By the way: creating a separate integration test config in Maven is painful, up to the point that people recommend to just add a new subproject that contains them. Yay, more nesting!
Think of the people who come to join your project! I've seen SBT modules with 5 different scala source directories and no obvious relationship between what depends on what, and good luck getting any IDE to understand whether test depends on integration-test or vice versa (most will give up and just build everything together, which is fine until you add something that works in the IDE and then errors when you build it with SBT).
A separate submodule is a much better approach - tools and people are much better at handling "module A depends on module B" than "this source folder depends on that source folder".
I believe the tagline/motto of every build tool should be “Don’t worry; You’ll get used to it.”
