PowerShell mill.bat: -Dkey=value with unquoted dotted value fails with misleading file-lock error

[odenix]

On Windows PowerShell, invoking mill.bat with -Dkey=0.1.0 fails with a misleading file-lock error during build script resolution.

Minimal build.mill:

import mill.*

object `package` extends RootModule {
  def printProperty() = Task.Command {
    println(System.getProperty("RELEASE_VERSION"))
  }
}

Failing command:

.\mill.bat -DRELEASE_VERSION=0.1.0 printProperty

Actual behavior:

Mill appears to receive .1.0 printProperty rather than the intended system property argument, then fails with:

java.io.IOException: The process cannot access the file because another process has locked a portion of the file
    at mill.api.PathRef$.apply(PathRef.scala:132)
    at mill.api.BuildCtx$.evalWatch(BuildCtx.scala:69)
    at mill.eval.ScriptModuleInit.resolveScriptModule(ScriptModuleInit.scala:197)

Expected behavior:

Either accept -Dkey=0.1.0, or reject it with a clear argument parsing error. It should not fail with a file-lock error.

These forms work in Powershell:

.\mill.bat -DRELEASE_VERSION="0.1.0" printProperty
.\mill.bat -D RELEASE_VERSION=0.1.0 printProperty
.\mill.bat --define RELEASE_VERSION=0.1.0 printProperty

In cmd.exe, this form also works:

mill.bat -DRELEASE_VERSION=0.1.0 printProperty

Environment:

Mill Build Tool version 1.1.5-44-d4c442
java.version: 21.0.10
java.vendor: Eclipse Adoptium
file.encoding: UTF-8
os.name: Windows 11
os.version: 10.0
os.arch: amd64

[lefou]

Not that familiar with all the Windows intricacies, but this could be as well a general limitation or feature of PowerShell. You probably should quote the full argument if it contains more than just letters and numbers, or learn more about the specific intricacies of PowerShell.

[odenix]

The underlying issue is that malformed input such as .\mill.bat .0.0 reproducibly leads to a file lock error with a long stack trace instead of a clear CLI error. For comparison, .\gradlew.bat .0.0 fails with "Task '.0.0' not found".

[lefou]

In what way is this input "malformed"?

[lefou]

So, we have two issues here?

1. Improper support for unquoted -D<key>=<value> CLI syntax in PowerShell
2. Missing compact error message (but a long misleading stacktrace) when a CLI argument can't be resolved

[odenix]

I think (2) is a Mill bug. Mill should either support or reject .0.0 consistently on supported platforms.

(1) is probably the user’s responsibility. I’m not sure whether mill.bat could compensate for it; gradlew.bat doesn’t. However, Gradle does seem to support a task named .0.0.