Basically there is no difference between build.sbt and project/build.sbt - they are both build.sbt , but their location makes a difference in how and what part of the project assembly they configure.
Quote sbt is recursive :
The project directory is another project within your project that knows how to build your project. A project inside a project can (in theory) do everything that any other project can do. Your build definition is sbt project.
And the turtles go down. If you want, you can customize the build project definition of the build definition by creating project/project/ .
There are two direct ways to create an assembly for your project using sbt files - <<26> in the main directory of your project and project/*.scala files. All of these files make up the assembly.
However, it is possible to configure the assembly for the newly configured assembly and the same rules apply - you can use (pay attention to project to the directory in front of the locations) project/*.sbt and project/project/*.scala files.
And the turtles go all the way down.
To expand the build of the project, you can use sbt plugins — the build configuration put together to make installation easier. They are part of the assembly assembly of your project (the assembly has been doubled for its intended purpose). By convention, plugins are installed in project/plugins.sbt , but any .sbt file under the project directory will be fine.
To make the story short, if you want to set the key in the assembly definition, you must use .sbt or project/*.scala .sbt files at a level that matches the assembly definition. If this is the top-level definition for your project, go to build.sbt in the root directory.
Remember that any assembly definition in project becomes part of the assembly definition of your project. [And the turtles go all the way down] [3], remember?