Merge branch 'main' into pr/java-module-cs-project

.config/mill-version

@@ -1 +1 @@
-0.12.3-75-c2bc74
+0.12.4

.github/workflows/scala-steward.yml

@@ -19,6 +19,6 @@ jobs:
           java-version: '17'
           distribution: 'temurin'
 
-      - uses: scala-steward-org/scala-steward-action@v2.71.0
+      - uses: scala-steward-org/scala-steward-action@v2.72.0
         with:
           mill-version: 0.12.1

blog/antora.yml

@@ -0,0 +1,8 @@
+name: blog
+title: Mill Blog
+version: ~
+nav:
+  - modules/ROOT/nav.adoc
+asciidoc:
+  attributes:
+    mill-version: dummy-mill-version

blog/modules/ROOT/nav.adoc

@@ -0,0 +1,3 @@
+
+* xref:2-monorepo-build-tool.adoc[]
+* xref:1-java-compile.adoc[]

docs/modules/ROOT/pages/comparisons/java-compile.adoc → blog/modules/ROOT/pages/1-java-compile.adoc

@@ -1,6 +1,13 @@
+// tag::header[]
+
 # How Fast Does Java Compile?
+:page-aliases: xref:mill:ROOT:comparisons/java-compile.adoc
+
+:author: Li Haoyi
+:revdate: 29 November 2024
+_{author}, {revdate}_
 
-include::partial$gtag-config.adoc[]
+include::mill:ROOT:partial$gtag-config.adoc[]
 
 Java compiles have the reputation for being slow, but that reputation does
 not match today's reality. Nowadays the Java compiler can compile "typical" Java code at over
@@ -24,6 +31,8 @@ all build tools fall short of how fast compiling Java _should_ be. This post exp
 these numbers were arrived at, and what that means in un-tapped potential for Java build
 tooling to become truly great.
 
+// end::header[]
+
 ## Mockito Core
 
 To begin to understand the problem, lets consider the codebase of the popular Mockito project:
@@ -291,8 +300,8 @@ Tabulating this all together gives us the table we saw at the start of this page
 | Gradle | 4.41s | 9,400 | 15.2x | Maven | 4.89s | 6,100 | 16.9x
 |===
 
-We explore the comparison between xref:comparisons/gradle.adoc[Gradle vs Mill]
-or xref:comparisons/maven.adoc[Maven vs Mill] in more detail on their own dedicated pages.
+We explore the comparison between xref:mill:ROOT:comparisons/gradle.adoc[Gradle vs Mill]
+or xref:mill:ROOT:comparisons/maven.adoc[Maven vs Mill] in more detail on their own dedicated pages.
 For this article, the important thing is not comparing the build tools against each other,
 but comparing the build tools against what how fast they _could_ be if they just used
 the `javac` Java compiler directly. And it's clear that compared to the actual work
@@ -307,8 +316,8 @@ we explored above only deals with compiling a single small module. But a similar
 Clean Compile* benchmarks which compiles the entire Mockito and Netty projects on
 a single core shows similar numbers for the various build tools:
 
-* xref:comparisons/gradle.adoc#_sequential_clean_compile_all[Gradle compiling 100,000 lines of Java at ~5,600 lines/s]
-* xref:comparisons/maven.adoc#_sequential_clean_compile_all[Maven compiling 500,000 lines of Java at ~5,100 lines/s]
+* xref:mill:ROOT:comparisons/gradle.adoc#_sequential_clean_compile_all[Gradle compiling 100,000 lines of Java at ~5,600 lines/s]
+* xref:mill:ROOT:comparisons/maven.adoc#_sequential_clean_compile_all[Maven compiling 500,000 lines of Java at ~5,100 lines/s]
 * Mill compiling at ~25,000 lines/s on both the above whole-project benchmarks
 
 All of these are far below the 100,000 lines/s that we should expect from Java compilation,
@@ -342,7 +351,7 @@ compiling Java_ is pure overhead. Checking for cache invalidation in _shouldn't_
 as long as actually compiling your code. I mean it obviously does _today_, but it _shouldn't_!
 
 The Mill build tool goes to great lengths to try and minimize overhead, and already gets
-xref:comparisons/why-mill.adoc#_performance[~4x faster builds] than Maven or Gradle on
+xref:mill:ROOT:comparisons/why-mill.adoc#_performance[~4x faster builds] than Maven or Gradle on
 real-world projects like Mockito or Netty. But there still is a long way to go give Java
 developers the fast, snappy experience that the underlying Java platform can provide. If
 Java build and compile times are things you find important, you should try out Mill on

blog/modules/ROOT/pages/index.adoc

@@ -0,0 +1,17 @@
+# Mill Build Tool Engineering Blog
+
+include::mill:ROOT:partial$gtag-config.adoc[]
+
+
+Welcome to the Mill development blog! This page contains posts and articles on
+technical topics related to the development of the Mill build tool. These discuss
+topics related to JVM languages and monorepo build tooling.
+
+include::2-monorepo-build-tool.adoc[tag=header,leveloffset=1]
+
+xref:2-monorepo-build-tool.adoc[Read More...]
+
+include::1-java-compile.adoc[tag=header,leveloffset=1]
+
+xref:1-java-compile.adoc[Read More...]
+

build.mill

@@ -38,11 +38,11 @@ object Settings {
   )
   val docTags: Seq[String] = Seq(
     "0.11.13",
-    "0.12.3"
+    "0.12.4"
   )
   val mimaBaseVersions: Seq[String] =
     0.to(13).map("0.11." + _) ++
-    Seq("0.12.0", "0.12.1", "0.12.2", "0.12.3")
+    Seq("0.12.0", "0.12.1", "0.12.2", "0.12.3", "0.12.4")
 }
 
 object Deps {
@@ -488,6 +488,7 @@ trait MillStableScalaModule extends MillPublishScalaModule with Mima {
     // (5x) MIMA doesn't properly ignore things which are nested inside other private things
     // so we have to put explicit ignores here (https://github.com/lightbend/mima/issues/771)
     ProblemFilter.exclude[Problem]("mill.eval.ProfileLogger*"),
+    ProblemFilter.exclude[Problem]("mill.eval.ChromeProfileLogger*"),
     ProblemFilter.exclude[Problem]("mill.eval.GroupEvaluator*"),
     ProblemFilter.exclude[Problem]("mill.eval.EvaluatorCore*"),
     ProblemFilter.exclude[Problem]("mill.eval.Tarjans*"),

docs/modules/ROOT/nav.adoc

@@ -40,7 +40,6 @@
 ** xref:comparisons/gradle.adoc[]
 ** xref:comparisons/sbt.adoc[]
 ** xref:comparisons/unique.adoc[]
-** xref:comparisons/java-compile.adoc[]
 * The Mill CLI
 ** xref:cli/installation-ide.adoc[]
 ** xref:cli/flags.adoc[]
@@ -101,7 +100,8 @@
 
 * Mill In Depth
 ** xref:depth/sandboxing.adoc[]
-** xref:depth/evaluation-model.adoc[]
+** xref:depth/execution-model.adoc[]
+** xref:depth/process-architecture.adoc[]
 ** xref:depth/design-principles.adoc[]
 ** xref:depth/why-scala.adoc[]
 // Reference pages that a typical user would not typically read top-to-bottom,

docs/modules/ROOT/pages/comparisons/gradle.adoc

@@ -18,7 +18,7 @@ does so with much less fixed overhead. This means less time waiting for your bui
 tool, and more time for the things that really matter to your project.
 
 * **Mill enforces best practices by default**.
-xref:depth/evaluation-model.adoc#_caching_at_each_layer_of_the_evaluation_model[All parts of a Mill build are cached and incremental by default].
+xref:depth/execution-model.adoc#_caching_in_mill[All parts of a Mill build are cached and incremental by default].
 All Mill tasks write their output to xref:fundamentals/out-dir.adoc[a standard place].
 All task inter-dependencies are automatically captured without manual annotation. Where Gradle requires
 considerable effort and expertise to understand your build and set it up in the right way, Mill's

docs/modules/ROOT/pages/comparisons/unique.adoc

@@ -480,7 +480,7 @@ functionality, but at 10% the complexity:
 * Bazel itself is not getting any simpler over time - instead is getting more complex with
   additional features and functionality, as tends to happen to projects over time
 
-Mill provides many of the same things Bazel does: automatic xref:depth/evaluation-model.adoc[caching],
+Mill provides many of the same things Bazel does: automatic xref:depth/execution-model.adoc[caching],
 parallelization, xref:depth/sandboxing.adoc[sandboxing],
 xref:extending/import-ivy-plugins.adoc[extensibility]. Mill
 can already work with a wide variety of programming languages,