Debugging Your Build

Debugging Setting

SBT offers a few helpful commands that may be used to understand your build and identify potential problem areas.

Show Command

The show command displays the return value of any sbt task. For example, if you're unsure whether a certain source file is being compiled, you may use show sources to determine if sbt is included in the sources:

[my-first-app] $ show sources
[info] ArrayBuffer(my-first-app/app/controllers/Application.scala, 
  my-first-app/target/scala-2.13/twirl/main/views/html/index.template.scala,
  my-first-app/target/scala-2.13/twirl/main/views/html/main.template.scala,
  my-first-app/target/scala-2.13/src_managed/main/routes_reverseRouting.scala,
  my-first-app/target/scala-2.13/src_managed/main/routes_routing.scala,
  my-first-app/target/scala-2.13/src_managed/main/controllers/routes.java)

You can also try this code with Online Java Compiler

Run Code

Inspect Command

The inspect command displays specific information about a task, such as what it depends on, where it was declared, and so on. You may use it similarly to the show command:

[my-first-app] $ inspect managedSources
[info] Task: scala.collection.Seq[java.io.File]
[info] Description:
[info]  Sources generated by the build.
[info] Provided by:
[info]  {file:my-first-app/}root/compile:managedSources
[info] Defined at:
[info]  (sbt.Defaults) Defaults.scala:185
[info] Dependencies:
[info]  compile:sourceGenerators
[info] Reverse dependencies:
[info]  compile:sources
...

You can also try this code with Online Java Compiler

Run Code

The managedSources command, which we have examined in this case, informs us that this is a job that generates a series of files and contains a description of Sources produced by the build. You can see that it depends on both the sources and sourceGenerators tasks.

Inspect Tree Command

A complete tree of task dependencies for a certain job is displayed using the inspect tree command. If we look at the unmanagedSources task's tree, we can see it as follows:

[my-first-app] $ inspect tree unmanagedSources
[info] compile:unmanagedSources = Task[scala.collection.Seq[java.io.File]]
[info]   +-*/*:sourcesInBase = true
[info]   +-*/*:unmanagedSources::includeFilter = sbt.SimpleFilter@3dc46f24
[info]   +-compile:unmanagedSourceDirectories = List(my-first-app/app, my-first-a..
[info]   | +-compile:javaSource = app
[info]   | | +-*:baseDirectory = my-first-app
[info]   | |   +-*:thisProject = Project(id root, base: my-first-app, configurations: List(compile,..
[info]   | |   
[info]   | +-compile:scalaSource = app
[info]   |   +-*:baseDirectory = my-first-app
[info]   |     +-*:thisProject = Project(id root, base: my-first-app, configurations: List(compile,..
[info]   |     
[info]   +-*:baseDirectory = my-first-app
[info]   +-*/*:excludeFilter = sbt.HiddenFileFilter$@49e479da

You can also try this code with Online Java Compiler

Run Code

This shows the whole pipeline used by SBT to find the sources in your project, including the filters used to select which files should be included or omitted. The inspect tree command comes in handy when you're unsure of how a certain component of your build is organized and want to see how everything fits together before delving further.

Debugging Incremental Compilation

People frequently complain that Play reloads and recompiles when they didn't expect it to. This frequently results from code generators or IDEs that unintentionally alter Play's classpath components, necessitating a reload. We may review the build task's debug log to troubleshoot issues like these. Whether it displays the log output or not, sbt collects it all throughout task execution so that you may review it later. Use the last command to inspect it.

Let's assume that after compilation, a file has to be recompiled:

[my-first-app] $ compile
[info] Compiling 1 Scala source to my-first-app/target/scala-2.13/classes...

You can also try this code with Online Java Compiler

Run Code

By running the last compile, you may retrieve a full debug log of what happened during the compile command. There will be a lot of output from this, but just the first section, which is displayed below, is of relevance to us.

[my-first-app] $ last compile
[debug]
[debug] Initial source changes:
[debug]  removed:Set()
[debug]  added: Set()
[debug]  modified: Set(my-first-app/app/controllers/Application.scala)
[debug] Removed products: Set()
[debug] External API changes: API Changes: Set()
[debug] Modified binary dependencies: Set()
[debug] Initial directly invalidated sources: Set(my-first-app/app/controllers/Application.scala)
[debug]
[debug] Sources indirectly invalidated by:
[debug]  product: Set()
[debug]  binary dep: Set()
[debug]  external source: Set()

You can also try this code with Online Java Compiler

Run Code

Frequently Asked Questions

What is the use of the play framework?

Play Framework is a free, open-source web application based on the model-view-controller (MVC) architectural paradigm. It is built on Akka and delivers predictable and low resource usage (CPU, memory, threads) for highly scalable applications.

What is debugging?

It is the process of identifying and removing computer hardware or software errors.

What does SBT stand for?

SBT stands for System Build Tools.

What is MVC?

MVC is an architectural paradigm that divides an application into three basic logical components: the model, the view, and the controller.

What is HTTP?

HTTP stands for Hypertext Transfer Protocol is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers.

Conclusion

In this article, we have extensively discussed how to debug build in the Play framework and different debugging commands. If you want to learn more, check out our articles on What Is Web2Py?, What is Sinatra?, Why To Use Web2py?, Postbacks and Internationalization in web2py, Third Party Modules In Web2py, Tasks In Web2py, and  XML in Web2py.

Do upvote our blog to help other ninjas grow.

Happy Coding!