WithJvmWorkerModule

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

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)

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. 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.

Returns a string representation of the object.

The default representation is platform dependent.