From f199707309bbb054b168f45551ae695e2efe3d4a Mon Sep 17 00:00:00 2001 From: Li Haoyi Date: Fri, 4 Oct 2024 15:41:48 +0800 Subject: [PATCH] . --- contrib/gitlab/readme.adoc | 2 +- contrib/playlib/readme.adoc | 2 +- contrib/versionfile/readme.adoc | 8 +-- .../ROOT/pages/depth/cross-builds.adoc | 2 +- .../ROOT/pages/depth/evaluation-model.adoc | 6 +- .../ROOT/pages/depth/library-deps.adoc | 6 +- docs/modules/ROOT/pages/depth/modules.adoc | 2 +- docs/modules/ROOT/pages/depth/out-dir.adoc | 20 +++--- .../ROOT/pages/depth/query-syntax.adoc | 54 +++++++------- docs/modules/ROOT/pages/depth/tasks.adoc | 10 +-- .../ROOT/pages/extending/meta-build.adoc | 4 +- .../pages/extending/thirdparty-plugins.adoc | 8 +-- .../ROOT/pages/javalib/module-config.adoc | 2 +- .../ROOT/pages/kotlinlib/module-config.adoc | 2 +- .../pages/reference/design-principles.adoc | 72 +++++++++---------- .../ROOT/pages/scalalib/module-config.adoc | 6 +- .../partials/Installation_IDE_Support.adoc | 4 +- .../basic/4-builtin-commands/build.mill | 7 +- idea/src/mill/idea/GenIdea.scala | 2 +- .../src/MultiLevelBuildTests.scala | 30 ++++---- main/src/mill/main/RunScript.scala | 2 +- 21 files changed, 126 insertions(+), 125 deletions(-) diff --git a/contrib/gitlab/readme.adoc b/contrib/gitlab/readme.adoc index c3b9ff28c9c..f245c0dc0fa 100644 --- a/contrib/gitlab/readme.adoc +++ b/contrib/gitlab/readme.adoc @@ -33,7 +33,7 @@ object lib extends ScalaModule with GitlabPublishModule { `publishVersion` and `pomSettings` come from `PublishModule`. `GitlabPublishModule` requires you to -set `publishRepository` for target of artifact publishing. Note that this *must* be a +set `publishRepository` for task of artifact publishing. Note that this *must* be a project repository defined by project id (publishing to other type of repositories is not https://docs.gitlab.com/ee/user/packages/maven_repository/#use-the-gitlab-endpoint-for-maven-packages[supported]). diff --git a/contrib/playlib/readme.adoc b/contrib/playlib/readme.adoc index a3c9805adaa..ca36f54f2af 100644 --- a/contrib/playlib/readme.adoc +++ b/contrib/playlib/readme.adoc @@ -168,7 +168,7 @@ object core extends PlayApiModule { == Commands equivalence -Mill commands are targets on a named build. For example if your build is called `core`: +Mill commands are tasks on a named build. For example if your build is called `core`: * compile: `core.compile` * run: _NOT Implemented yet_. It can be approximated with `mill -w core.runBackground` but this diff --git a/contrib/versionfile/readme.adoc b/contrib/versionfile/readme.adoc index bbe1b0c37da..a464814e6cf 100644 --- a/contrib/versionfile/readme.adoc +++ b/contrib/versionfile/readme.adoc @@ -4,8 +4,8 @@ This plugin provides helpers for updating a version file and committing the changes to git. -*Note: You can still make manual changes to the version file in-between execution of the targets provided by the module.* -*Each target operates on the version file as is at the time of execution.* +*Note: You can still make manual changes to the version file in-between execution of the tasks provided by the module.* +*Each task operates on the version file as is at the time of execution.* == Quickstart @@ -83,7 +83,7 @@ In this example, it would look for the file `version` in the same directory as t == Set release version -The `setReleaseVersion` target removes the `-SNAPSHOT` identifier from the version, +The `setReleaseVersion` task removes the `-SNAPSHOT` identifier from the version, then overwrites the previous content in the version file with this new version. === Example @@ -99,7 +99,7 @@ This will update the version file to contain `0.1.0`. == Set next version -The `setNextVersion` target bumps the version and changes it to a snapshot version, +The `setNextVersion` task bumps the version and changes it to a snapshot version, then overwrites the previous content in the version file with this new version. === Parameters diff --git a/docs/modules/ROOT/pages/depth/cross-builds.adoc b/docs/modules/ROOT/pages/depth/cross-builds.adoc index 8cd467299ba..b6c5246bf09 100644 --- a/docs/modules/ROOT/pages/depth/cross-builds.adoc +++ b/docs/modules/ROOT/pages/depth/cross-builds.adoc @@ -19,7 +19,7 @@ include::partial$example/depth/cross/11-default-cross-module.adoc[] include::partial$example/depth/cross/2-cross-source-path.adoc[] -== Using Cross Modules from Outside Targets +== Using Cross Modules from Outside Tasks include::partial$example/depth/cross/3-outside-dependency.adoc[] diff --git a/docs/modules/ROOT/pages/depth/evaluation-model.adoc b/docs/modules/ROOT/pages/depth/evaluation-model.adoc index 02bbe79faed..0b9a55535ca 100644 --- a/docs/modules/ROOT/pages/depth/evaluation-model.adoc +++ b/docs/modules/ROOT/pages/depth/evaluation-model.adoc @@ -1,7 +1,7 @@ = The Mill Evaluation Model :page-aliases: The_Mill_Evaluation_Model.adoc -Evaluating a Mill target typically goes through the following phases: +Evaluating a Mill task typically goes through the following phases: 1. *Compilation*: Mill compiles the `build.mill` to classfiles, following the <<_the_mill_bootstrapping_process>> to eventually produce a `RootModule` object @@ -73,8 +73,8 @@ the overall workflow remains fast even for large projects: * xref:depth/tasks.adoc#_targets[Target]s only re-evaluate if their input ``Task``s change. - * xref:depth/tasks.adoc#_persistent_targets[Task.Persistent]s preserve the `T.dest` folder on disk between runs, - allowing for finer-grained caching than Mill's default target-by-target + * xref:depth/tasks.adoc#_persistent_tasks[Task.Persistent]s preserve the `T.dest` folder on disk between runs, + allowing for finer-grained caching than Mill's default task-by-task caching and invalidation * xref:depth/tasks.adoc#_workers[Task.Worker]s are kept in-memory between runs where possible, and only diff --git a/docs/modules/ROOT/pages/depth/library-deps.adoc b/docs/modules/ROOT/pages/depth/library-deps.adoc index e60ab59bccc..8a3d1da5268 100644 --- a/docs/modules/ROOT/pages/depth/library-deps.adoc +++ b/docs/modules/ROOT/pages/depth/library-deps.adoc @@ -130,7 +130,7 @@ object main extends JavaModule { == Compile-only dependencies (`provided` scope) -If you want to use a dependency only at compile time, you can declare it with the `compileIvyDeps` target. +If you want to use a dependency only at compile time, you can declare it with the `compileIvyDeps` task. .Example [source,scala] @@ -142,12 +142,12 @@ def compileIvyDeps = Agg( When Mill generated file to interact with package manager like `pom.xml` for Maven repositories, such compile-only dependencies are mapped to the `provided` scope. -Please note, that dependencies with `provided` scope will never be resolved transitively. Hence, the name "provided", as the target runtime needs to "provide" them, if they are needed. +Please note, that dependencies with `provided` scope will never be resolved transitively. Hence, the name "provided", as the task runtime needs to "provide" them, if they are needed. == Runtime dependencies -If you want to declare dependencies to be used at runtime (but not at compile time), you can use the `runIvyDeps` targets. +If you want to declare dependencies to be used at runtime (but not at compile time), you can use the `runIvyDeps` tasks. .Example [source,scala] diff --git a/docs/modules/ROOT/pages/depth/modules.adoc b/docs/modules/ROOT/pages/depth/modules.adoc index d2d2320c150..59ec5a051dc 100644 --- a/docs/modules/ROOT/pages/depth/modules.adoc +++ b/docs/modules/ROOT/pages/depth/modules.adoc @@ -42,7 +42,7 @@ object Bar extends mill.define.ExternalModule { ---- In the above example, `Bar` is an `ExternalModule` living within the `foo` -Java package, containing the `baz` target and `qux` command. Those can be run +Java package, containing the `baz` task and `qux` command. Those can be run from the command line via: [source,bash] diff --git a/docs/modules/ROOT/pages/depth/out-dir.adoc b/docs/modules/ROOT/pages/depth/out-dir.adoc index 4c01f69636d..6d23df8397e 100644 --- a/docs/modules/ROOT/pages/depth/out-dir.adoc +++ b/docs/modules/ROOT/pages/depth/out-dir.adoc @@ -51,23 +51,23 @@ out/ └── mill-server/VpZubuAK6LQHHN+3ojh1LsTZqWY=-1/ ---- -<1> The `main` directory contains all files associated with target and submodules of the `main` module. -<2> The `compile` target has tried to access its scratch space via `T.dest`. Here you will find the actual compile results. -<3> Two targets printed something out while they ran. You can find these outputs in the `*.log` files. -<4> Three targets are overridden but re-use the result of their `super`-targets in some way. You can find these result under the `*.super/` path. +<1> The `main` directory contains all files associated with tasks and submodules of the `main` module. +<2> The `compile` task has tried to access its scratch space via `T.dest`. Here you will find the actual compile results. +<3> Two tasks printed something out while they ran. You can find these outputs in the `*.log` files. +<4> Three tasks are overridden but re-use the result of their `super`-tasks in some way. You can find these result under the `*.super/` path. -== Target Metadata and Cached Files +== Task Metadata and Cached Files Each named task (``Target`` or ``Command``) that is run has a representation in the `out/` directory structure. The _module_ structure is reflected in the directories, so that each module of your project has a uniquely associated subdirectory under the `out/` directory. -Each _target_ is associated with one or multiple files and directories under its module directory. -The following files can be found for a target `foo`: +Each _task_ is associated with one or multiple files and directories under its module directory. +The following files can be found for a task `foo`: `foo.json`:: the cache-key and JSON-serialized return-value of the -`Target`/`Command`. +`Task`/`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 `foo.dest/` which are then referenced by `foo.json` via `PathRef` references. @@ -82,7 +82,7 @@ conflicting with another `Task`, but can name files within `foo.dest/` arbitrar optional, the `stdout`/`stderr` of the `Task`. This is also streamed to the console during evaluation. `foo.super/`:: - optional, holds target metadata for overridden targets, so whenever you use a `super.foo()` in your `foo` target, you will find the metadata of the inherited task(s) under this directory. + optional, holds task metadata for overridden tasks, so whenever you use a `super.foo()` in your `foo` task, you will find the metadata of the inherited task(s) under this directory. The `out/` folder is intentionally kept simple and user-readable. @@ -95,7 +95,7 @@ rebuilt, e.g. by deleting the `+out/main/+` or `+out/main/compile.*+` folders, b [WARNING] -- -Cleaning some target state by manually deleting files under `out/` may be convenient, but you need to be careful to always delete the `foo.json` file whenever you delete a `foo.dest/` or `foo.super/`. Otherwise, you risk running into hard to diagnose issues later. +Cleaning some task state by manually deleting files under `out/` may be convenient, but you need to be careful to always delete the `foo.json` file whenever you delete a `foo.dest/` or `foo.super/`. Otherwise, you risk running into hard to diagnose issues later. Instead, you should always give the `clean` command a try before manually deleting some file under `out/`. -- diff --git a/docs/modules/ROOT/pages/depth/query-syntax.adoc b/docs/modules/ROOT/pages/depth/query-syntax.adoc index 77a4bbceb6e..9ecd0609de7 100644 --- a/docs/modules/ROOT/pages/depth/query-syntax.adoc +++ b/docs/modules/ROOT/pages/depth/query-syntax.adoc @@ -1,12 +1,12 @@ -= Target Query Syntax -:page-aliases: Target_Query_Syntax.adoc += Task Query Syntax +:page-aliases: Task_Query_Syntax.adoc -When interacting with Mill from the CLI, you often need to select targets or modules. -In most places, where Mill accepts a target, it really accepts a target selector query, which is the name of a target in its simplest form, but it can also contain wildcards, type pattern and other special syntax, making it a powerful tool to select specific targets. +When interacting with Mill from the CLI, you often need to select tasks or modules. +In most places, where Mill accepts a task, it really accepts a task selector query, which is the name of a task in its simplest form, but it can also contain wildcards, type pattern and other special syntax, making it a powerful tool to select specific tasks. -== Selecting dedicated targets +== Selecting dedicated tasks -When invoking Mill, the simplest way to run a target is to give it with a fully qualified names. +When invoking Mill, the simplest way to run a task is to give it with a fully qualified names. Examples: @@ -16,17 +16,17 @@ Examples: > mill foo.testCached ---- -.Understanding target paths and path segments +.Understanding task paths and path segments **** -Each Mill module and target has a unique path. +Each Mill module and task has a unique path. Each part of the path is called _segment_. Segments are separated with a dot (`.`). They look like regular Scala class name qualifiers. There are two kind of segments: _label segments_ and _cross segments_. -_Label segments_ are the components of a target path and have the same restriction as Scala identifiers. +_Label segments_ are the components of a task path and have the same restriction as Scala identifiers. They must start with a letter and may contain letters, numbers and a limited set of special characters `-` (dash), `_` (underscore). They are used to denote Mill modules, tasks, but in the case of xref:depth/modules.adoc#external-modules[external modules] their Scala package names. @@ -37,17 +37,17 @@ When combined with <> which contain dots (`. **** -[#select-multiple-targets] -== Selecting multiple targets +[#select-multiple-tasks] +== Selecting multiple tasks -If you want to select more than one target, you have multiple options: +If you want to select more than one task, you have multiple options: -* <> +* <> * <> * <> -* <> +* <> -You can also combine these techniques to properly select your targets +You can also combine these techniques to properly select your tasks [#enumerations] == Enumerations @@ -57,7 +57,7 @@ Inside the curly braces you can place two or more selector paths, separated with Examples: -* `{foo,bar}` simple enumerates two targets, `foo` and `bar` +* `{foo,bar}` simple enumerates two tasks, `foo` and `bar` * `foo.{compile,run}` expands to `foo.compile` and `foo.run` * `+{_,foo.bar}.baz+` expands to `+_.baz+` and `foo.bar.baz` @@ -82,9 +82,9 @@ There are two wildcards, you can use as path segment. * `+__+` The double underscore acts as a placeholder for many segments. In particular, it can represent an empty segment. -With wildcards, you can get explicit control over the position of a target in the build tree. +With wildcards, you can get explicit control over the position of a task in the build tree. -E.g. the filter `+_._._.jar+` will match all jar targets, that are on the third-level of the build tree. +E.g. the filter `+_._._.jar+` will match all jar tasks, that are on the third-level of the build tree. [#type-filters] == Type filters for wildcard selections @@ -96,7 +96,7 @@ For module paths this means, the represented module needs to be an instance of t A type filter always starts with a wildcard (`+_+`, `+__+`) followed by a colon (`:`) and finally the _type qualifier_. The type is matched by its name and optionally by its enclosing types and packages, separated by a `.` sign. -Since this is also used to separate target path segments, a type selector segment containing a `.` needs to be enclosed in parentheses. +Since this is also used to separate task path segments, a type selector segment containing a `.` needs to be enclosed in parentheses. A fully qualified type can be denoted with the `+_root_+` package. [sh] @@ -121,19 +121,19 @@ You can also add more than one type filters to a wildcard. > mill resolve "__:JavaModule:^ScalaModule:^TestModule.jar" ---- -NOTE: Type filter are currently only supported for module selections, but not for target selections. -That means, you can't filter based on the result type of a target. +NOTE: Type filter are currently only supported for module selections, but not for task selections. +That means, you can't filter based on the result type of a task. -[#add-target-selector] -== Start a new target selector with `+` +[#add-task-selector] +== Start a new task selector with `+` -On the Mill CLI you can also start a complete new target selector with the `+` sign. +On the Mill CLI you can also start a complete new task selector with the `+` sign. -There is a subtile difference between the expansion of <>, <> and <> in contrast to the <>. +There is a subtile difference between the expansion of <>, <> and <> in contrast to the <>. -For all the former versions, Mill parses them into a complex but single target selector path and subsequent parameters are used for all resolved targets. +For all the former versions, Mill parses them into a complex but single task selector path and subsequent parameters are used for all resolved tasks. -Whereas the `+` start a completely new selector path to which you can also provide a different parameter list. This is important when using xref:depth/tasks.adoc#commands[command targets] which can accept their own parameters. The `JavaModule.run` command is an example. +Whereas the `+` start a completely new selector path to which you can also provide a different parameter list. This is important when using xref:depth/tasks.adoc#commands[command tasks] which can accept their own parameters. The `JavaModule.run` command is an example. ---- > mill foo.run hello # <1> diff --git a/docs/modules/ROOT/pages/depth/tasks.adoc b/docs/modules/ROOT/pages/depth/tasks.adoc index 456d010094e..43643255ac5 100644 --- a/docs/modules/ROOT/pages/depth/tasks.adoc +++ b/docs/modules/ROOT/pages/depth/tasks.adoc @@ -5,10 +5,10 @@ One of Mill's core abstractions is its _Task Graph_: this is how Mill defines, orders and caches work it needs to do, and exists independently of any support for building Scala. -Mill target graphs are primarily built using methods and macros defined on -`mill.define.Target`, aliased as `T` for conciseness: +Mill task graphs are primarily built using methods and macros defined on +`mill.define.Task`, aliased as `T` for conciseness: -- {mill-doc-url}/api/latest/mill/define/Target$.html[mill.define.Target] +- {mill-doc-url}/api/latest/mill/define/Task$.html[mill.define.Task] == Task Cheat Sheet @@ -44,9 +44,9 @@ include::partial$example/depth/tasks/3-anonymous-tasks.adoc[] include::partial$example/depth/tasks/4-inputs.adoc[] -=== Persistent Targets +=== Persistent Tasks -include::partial$example/depth/tasks/5-persistent-targets.adoc[] +include::partial$example/depth/tasks/5-persistent-tasks.adoc[] === Workers diff --git a/docs/modules/ROOT/pages/extending/meta-build.adoc b/docs/modules/ROOT/pages/extending/meta-build.adoc index 3194f10a022..8cf595d5697 100644 --- a/docs/modules/ROOT/pages/extending/meta-build.adoc +++ b/docs/modules/ROOT/pages/extending/meta-build.adoc @@ -24,8 +24,8 @@ $ mill --meta-level 1 mill.scalalib.scalafmt.ScalafmtModule/reformatAll sources ---- * `--meta-level 1` selects the first meta-build. Without any customization, this is the only built-in meta-build. -* `mill.scalalib.scalafmt.ScalafmtModule/reformatAll` is a generic task to format scala source files with Scalafmt. It requires the targets that refer to the source files as argument -* `sources` this selects the `sources` targets of the meta-build, which at least contains the `build.mill`. +* `mill.scalalib.scalafmt.ScalafmtModule/reformatAll` is a generic task to format scala source files with Scalafmt. It requires the tasks that refer to the source files as argument +* `sources` this selects the `sources` tasks of the meta-build, which at least contains the `build.mill`. == Finding plugin updates diff --git a/docs/modules/ROOT/pages/extending/thirdparty-plugins.adoc b/docs/modules/ROOT/pages/extending/thirdparty-plugins.adoc index 5b94bdea136..1cb7e1c097a 100644 --- a/docs/modules/ROOT/pages/extending/thirdparty-plugins.adoc +++ b/docs/modules/ROOT/pages/extending/thirdparty-plugins.adoc @@ -335,7 +335,7 @@ Found undeclared dependencies: (add these to ivyDeps) Found unimported dependencies: (remove these from ivyDeps) ivy"org.typelevel::cats-effect:3.3.6", -1 targets failed +1 tasks failed main.checkExplicitDeps Found 1 undeclared dependencies, 1 unimported dependencies ---- @@ -367,7 +367,7 @@ object g8 extends G8Module { } ---- -The most common target you'd then use is `mill g8.validate`. +The most common task you'd then use is `mill g8.validate`. == Git @@ -821,7 +821,7 @@ Project home: https://github.com/sake92/mill-powershell-completion == PublishM2 -_Since Mill `0.6.1-27-f265a4` there is a built-in `publishM2Local` target in `PublishModule`._ +_Since Mill `0.6.1-27-f265a4` there is a built-in `publishM2Local` task in `PublishModule`._ Mill plugin to publish artifacts into a local Maven repository. @@ -970,7 +970,7 @@ object project extends ScalaModule with ScalafixModule { /project/project/src/MyClass.scala:12:11: error: [DisableSyntax.var] mutable state should be avoided private var hashLength = 7 ^^^ -1 targets failed +1 tasks failed project.fix A Scalafix linter error was reported ---- diff --git a/docs/modules/ROOT/pages/javalib/module-config.adoc b/docs/modules/ROOT/pages/javalib/module-config.adoc index a4aee38aca7..2396d2364e6 100644 --- a/docs/modules/ROOT/pages/javalib/module-config.adoc +++ b/docs/modules/ROOT/pages/javalib/module-config.adoc @@ -76,7 +76,7 @@ include::partial$example/javalib/module/14-repository-config.adoc[] Under some circumstances (e.g. corporate firewalls), you may not have access maven central. The typical symptom will be error messages which look like this; ---- -1 targets failed +1 tasks failed mill.scalalib.ZincWorkerModule.classpath Resolution failed for 1 modules: -------------------------------------------- diff --git a/docs/modules/ROOT/pages/kotlinlib/module-config.adoc b/docs/modules/ROOT/pages/kotlinlib/module-config.adoc index 318edddb1fd..c2f535f69cf 100644 --- a/docs/modules/ROOT/pages/kotlinlib/module-config.adoc +++ b/docs/modules/ROOT/pages/kotlinlib/module-config.adoc @@ -78,7 +78,7 @@ include::partial$example/kotlinlib/module/14-repository-config.adoc[] Under some circumstances (e.g. corporate firewalls), you may not have access maven central. The typical symptom will be error messages which look like this; ---- -1 targets failed +1 tasks failed mill.scalalib.ZincWorkerModule.classpath Resolution failed for 1 modules: -------------------------------------------- diff --git a/docs/modules/ROOT/pages/reference/design-principles.adoc b/docs/modules/ROOT/pages/reference/design-principles.adoc index 169ae4ec71e..3fc4af36d21 100644 --- a/docs/modules/ROOT/pages/reference/design-principles.adoc +++ b/docs/modules/ROOT/pages/reference/design-principles.adoc @@ -28,12 +28,12 @@ dependency graph of ``Task``s. === Builds are hierarchical -The syntax for running targets from the command line `mill Foo.bar.baz` is -the same as referencing a target in Scala code, `Foo.bar.baz` +The syntax for running tasks from the command line `mill Foo.bar.baz` is +the same as referencing a task in Scala code, `Foo.bar.baz` Everything that you can run from the command line lives in an object hierarchy in your `build.mill` file. Different parts of the hierarchy can have different -``Target``s available: just add a new `def foo = Task {...}` somewhere and you'll be +``Task``s available: just add a new `def foo = Task {...}` somewhere and you'll be able to run it. Cross builds, using the `Cross` data structure, are just another kind of node in @@ -43,33 +43,33 @@ run something via `mill core.cross[a].printIt` while from code you use === Caching by default -Every `Target` in a build, defined by `def foo = Task {...}`, is cached by default. +Every `Task` in a build, defined by `def foo = Task {...}`, is cached by default. Currently this is done using a `foo.json` file in the `out/` folder. The -`Target` is also provided a `foo.dest/` path on the filesystem dedicated to it, for +`Task` is also provided a `foo.dest/` path on the filesystem dedicated to it, for it to store output files etc. -This happens whether you want it to or not. Every `Target` is cached, not just +This happens whether you want it to or not. Every `Task` is cached, not just the "slow" ones like `compile` or `assembly`. -Caching is keyed on the `.hashCode` of the returned value. For ``Target``s +Caching is keyed on the `.hashCode` of the returned value. For ``Task``s returning the contents of a file/folder on disk, they return `PathRef` instances whose hashcode is based on the hash of the disk contents. Serialization of the returned values is done using uPickle. === Functional Purity -Mill relies heavily on build targets being "pure": they only depend on their -input targets, and their only output is their return value. They do not +Mill relies heavily on build tasks being "pure": they only depend on their +input tasks, and their only output is their return value. They do not scribble all over the filesystem, reading and writing from random places. That is what allows us to be aggressive about caching and parallelizing the -evaluation of build targets during a build. +evaluation of build tasks during a build. Many kinds of build steps do require files on disk, and for that Mill provides -the `T.dest` folder. This is a folder on disk dedicated to each build target, +the `T.dest` folder. This is a folder on disk dedicated to each build task, so that it can read and write things to it without worrying about conflicts -with other targets that have their own `T.dest` folders. In effect, this makes -even file output "pure": we can know precisely where a target's output files -live when we need to invalidate them, and it allows multiple targets all +with other tasks that have their own `T.dest` folders. In effect, this makes +even file output "pure": we can know precisely where a task's output files +live when we need to invalidate them, and it allows multiple tasks all reading and writing to the filesystem to do so safely even when in parallel. === Short-lived build processes @@ -79,11 +79,11 @@ long-lived daemon/console. That means we must minimize the startup time of the process, and that a new process must be able to re-construct the in-memory data structures where a previous process left off, in order to continue the build. -Re-construction is done via the hierarchical nature of the build: each `Target` +Re-construction is done via the hierarchical nature of the build: each `Task` `foo.bar.baz` has a fixed position in the build hierarchy, and thus a fixed position on disk `out/foo/bar/baz.json`. When the old process dies and a -new process starts, there will be a new instance of `Target` with the same -implementation code and same position in the build hierarchy: this new `Target` +new process starts, there will be a new instance of `Task` with the same +implementation code and same position in the build hierarchy: this new `Task` can then load the `out/foo/bar/baz.json` file and pick up where the previous process left off. @@ -100,7 +100,7 @@ good is a core ongoing requirement. dependency graph before we start executing ``Task``s. This lets us perform all sorts of useful operations on the graph before running it: -* Given a Target the user wants to run, pre-compute and display what targets +* Given a Task the user wants to run, pre-compute and display what tasks will be evaluated ("dry run"), without running them * Automatically parallelize different parts of the dependency graph that do not @@ -111,8 +111,8 @@ sorts of useful operations on the graph before running it: * Query the graph, e.g. "why does this thing depend on that other thing?" -* Avoid running tasks "halfway": if a Target's upstream Targets fail, we can - skip the Target completely rather than running halfway and then bailing out +* Avoid running tasks "halfway": if a Task's upstream Tasks fail, we can + skip the Task completely rather than running halfway and then bailing out with an exception In order to avoid making people using `.map` and `.zip` all over the place when @@ -216,10 +216,10 @@ digraph G { The module hierarchy is the graph of objects, starting from the root of the `build.mill` file, that extend `mill.Module`. At the leaves of the hierarchy are -the ``Target``s you can run. +the ``Task``s you can run. -A ``Target``'s position in the module hierarchy tells you many things. For -example, a `Target` at position `core.test.compile` would: +A ``Task``'s position in the module hierarchy tells you many things. For +example, a `Task` at position `core.test.compile` would: * Cache output metadata at `out/core/test/compile.json` @@ -229,12 +229,12 @@ example, a `Target` at position `core.test.compile` would: * Be runnable from the command-line via `mill core.test.compile` -* Be referenced programmatically (from other ``Target``s) via `core.test.compile` +* Be referenced programmatically (from other ``Task``s) via `core.test.compile` -From the position of any `Target` within the object hierarchy, you immediately +From the position of any `Task` within the object hierarchy, you immediately know how to run it, find its output files, find any caches, or refer to it from -other ``Target``s. You know up-front where the ``Target``s data "lives" on disk, and -are sure that it will never clash with any other ``Target``s data. +other ``Task``s. You know up-front where the ``Task``s data "lives" on disk, and +are sure that it will never clash with any other ``Task``s data. === The Call Graph @@ -276,21 +276,21 @@ digraph G { } .... -The Scala call graph of "which target references which other target" is core to +The Scala call graph of "which task references which other task" is core to how Mill operates. This graph is reified via the `T {...}` macro to make it available to the Mill execution engine at runtime. The call graph tells you: -* Which ``Target``s depend on which other ``Target``s +* Which ``Task``s depend on which other ``Task``s -* For a given `Target` to be built, what other ``Target``s need to be run and in +* For a given `Task` to be built, what other ``Task``s need to be run and in what order -* Which ``Target``s can be evaluated in parallel +* Which ``Task``s can be evaluated in parallel -* What source files need to be watched when using `--watch` on a given target (by +* What source files need to be watched when using `--watch` on a given task (by tracing the call graph up to the ``Source``s) -* What a given `Target` makes available for other ``Target``s to depend on (via +* What a given `Task` makes available for other ``Task``s to depend on (via its return value) * Defining your own task that depends on others is as simple as `def foo = @@ -309,11 +309,11 @@ val a = f(b, c, d) you are telling everyone that the value `a` depends on the values of `b` `c` and `d`, processed by `f`. A build tool needs exactly the same data structure: -knowing what `Target` depends on what other ``Target``s, and what processing it +knowing what `Task` depends on what other ``Task``s, and what processing it does on its inputs! With Mill, you can take the Scala call graph, wrap everything in the `T {...}` -macro, and get a `Target`-dependency graph that matches exactly the call-graph +macro, and get a `Task`-dependency graph that matches exactly the call-graph you already had: [source,scala] @@ -340,7 +340,7 @@ and over. In Mill, inheriting from traits is the primary way for re-using common parts of a build: -* Scala "project"s with multiple related ``Target``s within them, are just a +* Scala "project"s with multiple related ``Task``s within them, are just a `Trait` you instantiate * Replacing the default ``Target``s within a project, making them do new diff --git a/docs/modules/ROOT/pages/scalalib/module-config.adoc b/docs/modules/ROOT/pages/scalalib/module-config.adoc index 6d5686e63eb..af374823bf6 100644 --- a/docs/modules/ROOT/pages/scalalib/module-config.adoc +++ b/docs/modules/ROOT/pages/scalalib/module-config.adoc @@ -78,7 +78,7 @@ include::partial$example/scalalib/module/14-repository-config.adoc[] Under some circumstances (e.g. corporate firewalls), you may not have access maven central. The typical symptom will be error messages which look like this; ---- -1 targets failed +1 tasks failed mill.scalalib.ZincWorkerModule.classpath Resolution failed for 1 modules: -------------------------------------------- @@ -105,9 +105,9 @@ include::partial$example/scalalib/module/15-unidoc.adoc[] == Using the Ammonite Repl / Scala console -All ``ScalaModule``s have a `console` and a `repl` target, to start a Scala console or an Ammonite Repl. +All ``ScalaModule``s have a `console` and a `repl` task, to start a Scala console or an Ammonite Repl. -When using the `console`, you can configure its `scalac` options using the `consoleScalacOptions` target. +When using the `console`, you can configure its `scalac` options using the `consoleScalacOptions` task. For example, you may want to inherit all of your regular `scalacOptions` but disable `-Xfatal-warnings`: diff --git a/docs/modules/ROOT/partials/Installation_IDE_Support.adoc b/docs/modules/ROOT/partials/Installation_IDE_Support.adoc index bbe8b1b2a26..66b990e84ee 100644 --- a/docs/modules/ROOT/partials/Installation_IDE_Support.adoc +++ b/docs/modules/ROOT/partials/Installation_IDE_Support.adoc @@ -129,8 +129,8 @@ mill --debug mill.bsp.BSP/install A common issue for poor performance can be a mismatch of the JVMs. In such a case the Mill BSP server started by a BSP client like Metals is using a _different_ JVM than `mill` is using when started from the command line. -In such a scenario, every Mill invocation using the other JVM will inadvertently invalidate Mills target caches. -This effectively leads to full reevaluation of all invoked Mill targets and appears as "bad performance". +In such a scenario, every Mill invocation using the other JVM will inadvertently invalidate Mills task caches. +This effectively leads to full reevaluation of all invoked Mill tasks and appears as "bad performance". To detect if this is the case, diff --git a/example/scalalib/basic/4-builtin-commands/build.mill b/example/scalalib/basic/4-builtin-commands/build.mill index 0142131156d..e164b0058ba 100644 --- a/example/scalalib/basic/4-builtin-commands/build.mill +++ b/example/scalalib/basic/4-builtin-commands/build.mill @@ -164,8 +164,9 @@ Inputs: // `show` is also useful for interacting with Mill from external tools, since the // JSON it outputs is structured and easily parsed and manipulated. // -// When `show` is used with multiple targets, its output will slightly change to a -// JSON array, containing all the results of the given targets. +// When `show` is used with multiple task, its output will slightly change to a +// JSON dictionary, with the keys being the task names and the values being the +// JSON results of the given task. /** Usage @@ -185,7 +186,7 @@ Inputs: // == showNamed // Same as `show`, but the output will always be structured in a JSON -// dictionary, whether there is one or more targets in the selection +// dictionary, whether there is one or more task in the selection /** Usage diff --git a/idea/src/mill/idea/GenIdea.scala b/idea/src/mill/idea/GenIdea.scala index 3b2295dd00e..31b7fab6ebe 100644 --- a/idea/src/mill/idea/GenIdea.scala +++ b/idea/src/mill/idea/GenIdea.scala @@ -7,7 +7,7 @@ import mill.eval.Evaluator import scala.util.control.NonFatal -object GenIdea extends mill.define.TaskModule { +object GenIdea extends ExternalModule with mill.define.TaskModule { def defaultCommandName() = "idea" def idea(allBootstrapEvaluators: Evaluator.AllBootstrapEvaluators): Command[Unit] = Task.Command { try { diff --git a/integration/invalidation/multi-level-editing/src/MultiLevelBuildTests.scala b/integration/invalidation/multi-level-editing/src/MultiLevelBuildTests.scala index cc10a00640e..ba9554d6c7a 100644 --- a/integration/invalidation/multi-level-editing/src/MultiLevelBuildTests.scala +++ b/integration/invalidation/multi-level-editing/src/MultiLevelBuildTests.scala @@ -263,7 +263,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { checkChangedClassloaders(tester, null, true, true, true) causeParseError(workspacePath / "build.mill") - evalCheckErr(tester, "\n1 targets failed", "\ngenerateScriptSources build.mill") + evalCheckErr(tester, "\n1 tasks failed", "\ngenerateScriptSources build.mill") checkWatchedFiles(tester, Nil, buildPaths(tester), Nil, Nil) // When one of the meta-builds still has parse errors, all classloaders // remain null, because none of the meta-builds can evaluate. Only once @@ -273,7 +273,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { fixParseError(workspacePath / "build.mill") causeParseError(workspacePath / "mill-build/build.mill") - evalCheckErr(tester, "\n1 targets failed", "\ngenerateScriptSources mill-build/build.mill") + evalCheckErr(tester, "\n1 tasks failed", "\ngenerateScriptSources mill-build/build.mill") checkWatchedFiles(tester, Nil, Nil, buildPaths2(tester), Nil) checkChangedClassloaders(tester, null, null, null, null) @@ -281,7 +281,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { causeParseError(workspacePath / "mill-build/mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", "\ngenerateScriptSources mill-build/mill-build/build.mill" ) checkWatchedFiles(tester, Nil, Nil, Nil, buildPaths3(tester)) @@ -289,13 +289,13 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { fixParseError(workspacePath / "mill-build/mill-build/build.mill") causeParseError(workspacePath / "mill-build/build.mill") - evalCheckErr(tester, "\n1 targets failed", "\ngenerateScriptSources mill-build/build.mill") + evalCheckErr(tester, "\n1 tasks failed", "\ngenerateScriptSources mill-build/build.mill") checkWatchedFiles(tester, Nil, Nil, buildPaths2(tester), Nil) checkChangedClassloaders(tester, null, null, null, null) fixParseError(workspacePath / "mill-build/build.mill") causeParseError(workspacePath / "build.mill") - evalCheckErr(tester, "\n1 targets failed", "\ngenerateScriptSources build.mill") + evalCheckErr(tester, "\n1 tasks failed", "\ngenerateScriptSources build.mill") checkWatchedFiles(tester, Nil, buildPaths(tester), Nil, Nil) checkChangedClassloaders(tester, null, null, null, null) @@ -332,7 +332,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { causeCompileError(workspacePath / "build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", // Ensure the file path in the compile error is properly adjusted to point // at the original source file and not the generated file (workspacePath / "build.mill").toString, @@ -344,7 +344,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { causeCompileError(workspacePath / "mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", (workspacePath / "mill-build/build.mill").toString, "not found: object doesnt" ) @@ -354,7 +354,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { causeCompileError(workspacePath / "mill-build/mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", (workspacePath / "mill-build/mill-build/build.mill").toString, "not found: object doesnt" ) @@ -364,7 +364,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { fixCompileError(workspacePath / "mill-build/mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", (workspacePath / "mill-build/build.mill").toString, "not found: object doesnt" ) @@ -374,7 +374,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { fixCompileError(workspacePath / "mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", (workspacePath / "build.mill").toString, "not found: value doesnt" ) @@ -418,7 +418,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { checkChangedClassloaders(tester, null, true, true, true) causeRuntimeError(workspacePath / "build.mill") - evalCheckErr(tester, "\n1 targets failed", "foo.runClasspath java.lang.Exception: boom") + evalCheckErr(tester, "\n1 tasks failed", "foo.runClasspath java.lang.Exception: boom") checkWatchedFiles( tester, fooPaths(tester), @@ -431,7 +431,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { causeRuntimeError(workspacePath / "mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", "build.mill", "runClasspath java.lang.Exception: boom" ) @@ -441,7 +441,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { causeRuntimeError(workspacePath / "mill-build/mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", "build.mill", "runClasspath java.lang.Exception: boom" ) @@ -451,7 +451,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { fixRuntimeError(workspacePath / "mill-build/mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", "build.mill", "runClasspath java.lang.Exception: boom" ) @@ -461,7 +461,7 @@ object MultiLevelBuildTests extends UtestIntegrationTestSuite { fixRuntimeError(workspacePath / "mill-build/build.mill") evalCheckErr( tester, - "\n1 targets failed", + "\n1 tasks failed", "build.mill", "foo.runClasspath java.lang.Exception: boom" ) diff --git a/main/src/mill/main/RunScript.scala b/main/src/mill/main/RunScript.scala index 4c2d7070bbb..2478bcf4c8e 100644 --- a/main/src/mill/main/RunScript.scala +++ b/main/src/mill/main/RunScript.scala @@ -72,7 +72,7 @@ object RunScript { } watched -> Right(evaluated.values.zip(nameAndJson)) - case n => watched -> Left(s"$n targets failed\n$errorStr") + case n => watched -> Left(s"$n tasks failed\n$errorStr") } }