Although the silly "Expected ':'" is still there, the newer SBT versions show better output, there's even a "did you mean" feature.
Regarding "discovering which submodule you're supposed to run commands in": this is a non-issue. Commands are either run under the obvious subproject (e.g. "api/run", "business-logic/test"), or are run as top-level commands. This is true 99% of the time. I have a fairly complex project open right now, and I just run "docker:publishLocal" to create two separate Docker images, one for each subproject that includes the appropriate plugin. I think this is better than overloading a single command. SBT projects usually have a small readme describing what is the command for any specific task you're supposed to do. In Maven, you know the commands, but you need to read to ensure what they do (does "deploy" push to an artifact repository, does it create a container image, does it create a deb package, or does it create a standalone jar?).
The use case where a multimodule project becomes multiple projects is more gradual in Maven, I fully agree on this. The problem, as I said, lies in that child Maven projects are not self-contained. They usually depend on information declared in the parent builds. This breaks the assumption that people can work on a project without worrying about the parent project.
Finally, source dependencies are explicit in SBT save for the base case "test depends on main". Everything else must be specified, so it's either there in the build file, or added as part of a build plugin. It can also be checked from the REPL. And building from the IDE is a dumb mistake if the IDE doesn't use the correct build tool underneath: the build is there for a reason and the IDE shouldn't bypass it.
> does "deploy" push to an artifact repository, does it create a container image, does it create a deb package, or does it create a standalone jar?
"package" creates some kind of package, "deploy" pushes it to some kind of artifact repository. The details of what kind of package and what kind of repository will vary from project to project, but you don't need to know them to start work on the project. In theory there could be projects out there that do surprising things (after all, nothing actually stops you from configuring your build to push a container image to a repository when someone runs "mvn test"), but the overwhelming majority of projects find a way to fit themselves into the maven lifecycle, and it really reduces the "where do I start" effect when you check out a new project: I don't have to read the build file or hunt for documentation, I can run "mvn install" and see what it does, and be confident that that's "how you build this project".
> The problem, as I said, lies in that child Maven projects are not self-contained. They usually depend on information declared in the parent builds. This breaks the assumption that people can work on a project without worrying about the parent project.
Well, SBT projects also come with a bunch of default tasks that aren't defined explicitly in their project definition; some of them are defined by plugins and some of them are defined... somewhere (I genuinely don't know where the tasks that are available by default come from, or how to see a list of all of them except by using the interactive commands). So an SBT project is not self-contained in that sense either. In maven anything that's not explicitly defined in the project is coming from its parent pom, which is either the default parent pom or an explicitly specified one, and the default parent pom is a real pom that you can look at that follows the normal rules.
So you do have to understand the concept of a parent pom, but it's not an extra thing that you have to understand, because the default parent and any parent pom you're using in a multi-module project work exactly the same way.
> And building from the IDE is a dumb mistake if the IDE doesn't use the correct build tool underneath: the build is there for a reason and the IDE shouldn't bypass it.
Yes and no: the IDE has a bunch of knowledge of its own that the build tool doesn't, such as which files the user has changed, or which specific test the user has asked to run, or which import the user wants to add a dependency for. So I don't think the idea of the IDE dumbly invoking the build tool and letting it do its thing works (particularly in a language like Scala where you have to rely heavily on incremental compilation if you don't want enormous build times); instead there needs to be a deeper integration where the build tool and the IDE share a structured model of the project, and the IDE can perform a build via that model (effectively embedding part of the build tool as a library, if you like). Likewise I don't want to invoke a separate build REPL to understand the project definition, I want to be able to explore it within the IDE.
Regarding "discovering which submodule you're supposed to run commands in": this is a non-issue. Commands are either run under the obvious subproject (e.g. "api/run", "business-logic/test"), or are run as top-level commands. This is true 99% of the time. I have a fairly complex project open right now, and I just run "docker:publishLocal" to create two separate Docker images, one for each subproject that includes the appropriate plugin. I think this is better than overloading a single command. SBT projects usually have a small readme describing what is the command for any specific task you're supposed to do. In Maven, you know the commands, but you need to read to ensure what they do (does "deploy" push to an artifact repository, does it create a container image, does it create a deb package, or does it create a standalone jar?).
The use case where a multimodule project becomes multiple projects is more gradual in Maven, I fully agree on this. The problem, as I said, lies in that child Maven projects are not self-contained. They usually depend on information declared in the parent builds. This breaks the assumption that people can work on a project without worrying about the parent project.
Finally, source dependencies are explicit in SBT save for the base case "test depends on main". Everything else must be specified, so it's either there in the build file, or added as part of a build plugin. It can also be checked from the REPL. And building from the IDE is a dumb mistake if the IDE doesn't use the correct build tool underneath: the build is there for a reason and the IDE shouldn't bypass it.