AndroidTestModule

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

Environment variables to pass to the forked JVM.

Includes forkEnv and the variables defined by Mill itself.

All main classes detected in this module that can serve as program entry-points.

The repositories used to resolve dependencies

Unlike repositoriesTask, this includes the Mill internal repositories, which allow to resolve Mill internal modules (usually brought in via JavaModule#coursierDependency).

Beware that this needs to evaluate JavaModule#coursierProject of all module dependencies of the current module, which itself evaluates JavaModule#mvnDeps and related tasks. You shouldn't depend on this task from implementations of mvnDeps, which would introduce cycles between Mill tasks.

Bind a dependency (Dep) to the actual module context (e.g. the scala version and the platform suffix)

Use to fill most fields of BuildTarget.

Whether to enable Gradle Module support when fetching dependencies

Customize the coursier file cache.

This is rarely needed to be changed, but sometimes e.g. you want to load a coursier plugin. Doing so requires adding to coursier's classpath. To do this you could use the following:

 override def coursierCacheCustomizer = Task.Anon {
    Some( (fc: coursier.cache.FileCache[Task]) =>
      fc.withClassLoaders(Seq(classOf[coursier.cache.protocol.S3Handler].getClassLoader))
    )
 }

A CoursierModule.Resolver to resolve dependencies.

Can be used to resolve external dependencies, if you need to download an external tool from Maven or Ivy repositories, by calling CoursierModule.Resolver#classpath.

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

Test classes (often called test suites) discovered by the configured testFramework.

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

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

Optional custom Java Home for the JvmWorker to use

If this value is None, then the JvmWorker uses the same Java used to run the current mill instance.

Builds a command-line "launcher" file that can be used to run this module's code, without the Mill process. Useful for deployment & other places where you do not want a build tool running

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.

Map dependencies before resolving them. Override this to customize the set of dependencies.

A CoursierModule.Resolver to resolve dependencies.

Unlike defaultResolver, this resolver can resolve Mill modules too (obtained via JavaModule.coursierDependency).

The repositories used to resolve dependencies with classpath(). This takes Coursier repository strings as input which are defined here:

• https://github.com/coursier/coursier/blob/main/docs/pages/reference-repositories.md

For example:

• https://repo1.maven.org/maven2 Maven Central which is the most commonly used Maven repository

• file:///Users/alex/test-repo A local repository cache on disk

• file://${ivy.home-${user.home}/.ivy2}/local/[defaultPattern] The local Ivy2 repository where Mill, Scala CLI, or sbt publish to when asked to publish locally

• file://${user.home}/.m2/repository the local Maven repository. Use of this is not recommended for reasons explained in the link above

• https://maven.google.com Google-managed repository that distributes some Android artifacts in particular

A more flexible version of repositories, that allows custom repositories that are not definable by Coursier repository strings. This is a relatively advanced feature, and for most situations overriding repositories should be sufficient

See allRepositories if you need to resolve Mill internal modules.

Customize the coursier resolution process. This is rarely needed to changed, as the default try to provide a highly reproducible resolution process. But sometime, you need more control, e.g. you want to add some OS or JDK specific resolution properties which are sometimes used by Maven and therefore found in dependency artifact metadata. For example, the JavaFX artifacts are known to use OS specific properties. To fix resolution for JavaFX, you could override this task like the following:

   override def resolutionCustomizer = Task.Anon {
     Some( (r: coursier.core.Resolution) =>
       r.withOsInfo(coursier.core.Activation.Os.fromProperties(sys.props.toMap))
     )
   }

Resolution parameters, allowing to customize resolution internals

This rarely needs to be changed. This allows to disable the new way coursier handles BOMs since coursier 2.1.17 (used in Mill since 0.12.3) for example, with:

 def resolutionParams = super.resolutionParams()
   .withEnableDependencyOverrides(Some(false))

Note that versions forced with Dep#forceVersion() take over forced versions manually set in resolutionParams. The former should be favored to force versions in dependency resolution.

The Scala version set via ScalaModule#scalaVersion also takes over any Scala version provided via ResolutionParams#scalaVersionOpt.

The default configuration set in ResolutionParams#defaultConfiguration is ignored when Mill fetches dependencies to be passed to the compiler (equivalent to Maven "compile scope"). In that case, it forces the default configuration to be "compile". On the other hand, when fetching dependencies for runtime (equivalent to Maven "runtime scope"), the value in ResolutionParams#defaultConfiguration is used.

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

Runs this module's code in a background process, until it dies or runBackground is used again. This lets you continue using Mill while the process is running in the background: editing files, compiling, and only re-starting the background process when you're ready.

You can also use -w foo.runBackground to make Mill watch for changes and automatically recompile your code & restart the background process when ready. This is useful when working on long-running server processes that would otherwise run forever

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*-tasks 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. 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. Test classes from different groups are ensured to never run on the same JVM process, and therefore can be run in parallel. When used in combination with testParallelism, every JVM test running process will guarantee to never claim tests from different test groups.

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

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.

Whether to use the test parallelism to run tests in multiple JVM processes. When used in combination with testForkGrouping, every JVM test running process will guarantee to never claim tests from different test groups.

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.

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

Returns a string representation of the object.

The default representation is platform dependent.

The test framework to use to discover and run run tests.

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

Most of these provide additional xxxVersion tasks, to manage the test framework dependencies for you.