By default, sbt generates reports of all your dependencies, including dependency trees to show which dependencies transitively brought in other dependencies, and conflict resolution tables showing how sbt decided which version of a dependency it selected when multiple were requested.

The reports are generated into xml files, with an accompanying XSL stylesheet that allow browsers that support XSL to convert the XML reports into HTML. Browsers with this support include Firefox and Safari, and notably don’t include Chrome.

The reports can be found in the target/scala-2.12/resolution-cache/reports/ directory of your project, one is generated for each scope in your project, and are named organization-projectId_scalaVersion-scope.xml, for example, com.example-my-first-app_2.11-compile.xml. When opened in Firefox, this report looks something like this:

The show command shows the return value from any sbt task. So for example, if you’re not sure if a certain source file is being compiled or not, you can run show sources to see if sbt is including it in the sources:

The output above has been formatted to ensure it fits cleanly on the screen, you may need to copy it to an editor to make sense of it if the task you run returns a long list of items.

You can also specify a task a particular scope, eg test:sources or compile:sources, or for a particular project, my-project/compile:sources, and in some cases, where tasks are scoped by another task, you can specify that scope too, for example, to see everything that will be packaged into your projects jar file, you want to show the mappings task, scoped to the packageBin task:

Here we’ve inspected the managedSources command, it tells us that this is a task that produces a sequence of files, it has a description of Sources generated by the build. You can see that it depends on the sourceGenerators task, and the sources task depends on it. You can also see where it was defined, in this case, it’s from sbt’s default task definitions, line 185.

This shows the whole tree of tasks that sbt uses to discover the sources in your project, including the filters to decide which files to be included or excluded. The inspect tree command is particularly useful when you’re not sure how some part of your build is structured, and you want to find out how it all fits together so you can then dive in deeper.

A common problem that people have in Play is they find Play recompiles and reloads when they don’t expect it to. This is often caused by source generators or IDEs that inadvertently update elements of Play’s classpath, forcing a reload. To debug problems like this, we can look at the debug log from the compile task. When sbt runs a task it captures all the log output, whether it displays it or not, so that you can inspect it later if you want. It can be inspected using the last command.

Found an error in this documentation? The source code for this page can be found here. After reading the documentation guidelines, please feel free to contribute a pull request. Have questions or advice to share? Go to our community forums to start a conversation with the community.