RunModule

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.

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

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

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.

Whether or not to propagate the enclosing shell's environment variables to the .run or .testForked process. Defaults to true, which is convenient when you need to configure your subprocess or tests with environment variables, but can be set to false if you prefer having additional hermeticity.

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.

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#coursierDependencyTask).

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)

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.

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.

Map dependencies before resolving them - use only if you know what you are doing. Override this to customize the set of dependencies.

Using this makes it harder to make sense of dependency resolutions and to reproduce those resolutions via the coursier command-line or from other build tools.

A CoursierModule.Resolver to resolve dependencies.

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

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.

Returns a string representation of the object.

The default representation is platform dependent.