The Output Directory

Mill puts all its output in the top-level out/ folder. The above commands would end up in:







For each task there’s a foo.json file containing the metadata returned by that task, and two optional paths: a foo.dest/ folder containing any files that the task generates and a foo.log file containing the logs of running that task. For example, out/foo/compile.dest/ contains the compiled classfiles, while out/foo/assembly.dest/ contains the self-contained assembly with the project’s classfiles jar-ed up with all its dependencies.

Given a task, all its output and results are inside its respective out/foo/bar/ folder.

Structure of the out/ Directory

The out/ folder contains all the generated files & metadata for your build. It is structured with one folder per Target/Command, that is run, e.g.:

  • out/core/compile/

  • out/main/test/compile/

  • out/main/test/forkTest/

  • out/scalalib/compile/

There are also top-level build-related files in the out/ folder, prefixed as mill-*. The most useful is mill-profile.json, which logs the tasks run and time taken for the last Mill command you executed. This is very useful if you want to find out exactly what tasks are being run and Mill is being slow.

Each task currently creates contains the following files:

  • foo.dest/: optional, a path for the Task to use either as a scratch space, or to place generated files that are returned using PathRef references. A Task should only output files within its own given dest/ folder (available as T.dest) to avoid conflicting with another Task, but can name files within dest/ arbitrarily.

  • foo.log: optional, the stdout/stderr of the Task. This is also streamed to the console during evaluation.

  • foo.json: the cache-key and JSON-serialized return-value of the Target/Command. The return-value can also be retrieved via mill show foo.compile. Binary blobs are typically not included in foo.json, and instead stored as separate binary files in dest/ which are then referenced by foo.json via PathRef references.

The out/ folder is intentionally kept simple and user-readable. If your build is not behaving as you would expect, feel free to poke around the various foo.dest/ folders to see what files are being created, or the foo.json files to see what is being returned by a particular task. You can also simply delete folders within out/ if you want to force portions of your project to be rebuilt, e.g. by deleting the out/main/ or out/main/test/compile/ folders.