Miscellaneous machinery around traversing & querying the build hierarchy, that should not be needed by normal users of Mill

Use to fill most fields of BuildTarget.

Use to populate the BuildTarget.{dataKind,data} fields.

Mill specific implementations: - JvmBuildTarget - ScalaBuildTarget

The name of the default command, which will be automatically executed if the module name is provided at the Mill command line.

Overridden since Junit5 has its own discovery mechanism.

This is basically a re-implementation of sbt's plugin for Junit5 test discovery mechanism. See https://github.com/sbt/sbt-jupiter-interface/blob/468d4f31f1f6ce8529fff8a8804dd733974c7686/src/plugin/src/main/scala/com/github/sbt/junit/jupiter/sbt/JupiterPlugin.scala#L97C15-L118 for details.

Note that we access the test discovery via reflection, to avoid mill itself having a dependency on Junit5. Hence, if you remove the sbt-jupiter-interface dependency from ivyDeps, make sure to also override this method.

Any command-line parameters you want to pass to the forked JVM.

Any environment variables you want to pass to the forked JVM.

The elements of the run classpath which are local to this module. This is typically the output of a compilation step and bundles runtime resources.

Allows you to specify an explicit main class to use for the run command. If none is specified, the classpath is searched for an appropriate main class to use if one exists.

Runs this module's code in a subprocess and waits for it to finish

If true, stdout and stderr of the process executed by runBackground or runMainBackground is sent to mill's stdout/stderr (which usually flow to the console).

If false, output will be directed to files stdout.log and stderr.log in runBackground.dest (or runMainBackground.dest)

All classfiles and resources including upstream modules and dependencies necessary to run this module's code.

Runs this module's code in a subprocess and waits for it to finish

Runs this module's code in-process within an isolated classloader. This is faster than run, but in exchange you have less isolation between runs since the code can dirty the parent Mill process and potentially leave it in a bad state.

Same as run, but lets you specify a main class to run

Same as runBackground, but lets you specify a main class to run

Same as runLocal, but lets you specify a main class to run

Control whether run*-targets should use an args file to pass command line args, if possible.

Discovers and runs the module's tests in a subprocess, reporting the results to the console.

Discovers and runs the module's tests in a subprocess, reporting the results to the console. If no input has changed since the last run, no test were executed.

Args to be used by testCached.

The classpath containing the tests. This is most likely the output of the compilation target. By default, this uses the result of localRunClasspath, which is most likely the result of a local compilation.

How the test classes in this module will be split into multiple JVM processes and run in parallel during testing. Defaults to all of them running in one process sequentially, but can be overriden to split them into separate groups that run in parallel.

The test framework to use.

For convenience, you can also mix-in one of these predefined traits: - TestModule.Junit4 - TestModule.Junit5 - TestModule.Munit - TestModule.ScalaTest - TestModule.Specs2 - TestModule.TestNg - TestModule.Utest - TestModule.Weaver - TestModule.ZioTest

Discovers and runs the module's tests in-process in an isolated classloader, reporting the results to the console

Discovers and runs the module's tests in a subprocess, reporting the results to the console. Arguments before "--" will be used as wildcard selector to select test classes, arguments after "--" will be passed as regular arguments. testOnly *foo foobar bar* -- arguments will test only classes with name (includes package name) 1. end with "foo", 2. exactly "foobar", 3. start with "bar", with "arguments" as arguments passing to test framework.

Sets the file name for the generated JUnit-compatible test report. If None is set, no file will be generated.

Whether to use the test task destination folder as the working directory when running tests. true means test subprocess run in the .dest/sandbox folder of the test task, providing better isolation and encouragement of best practices (e.g. not reading/writing stuff randomly from the project source tree). false means the test subprocess runs in the project root folder, providing weaker isolation.

The actual task shared by test-tasks that runs test in a forked JVM.

Controls whether the TestRunner should receive its arguments via an args-file instead of a long parameter list. Defaults to what runUseArgsFile return.