Tobias Roeser

So, does that mean we don't need to take any precaution regarding case classes when rolling out Mill `1.0.0`? I understand `@unroll` will just generate all the overloads to keep...

Oh I see, the default values make the magic.

So, I tried to restart the build multiple times but it seems the failure isn't just flakiness but something else I still don't understand. Looks like the produced assembly isn't...

The test also fails with Mill `0.11.7-50-9a734a`, so there seems to be another issue than I thought. I will try to narrow it down further...

So, the assembly test fails when we bump the build tool Mill from version `0.11.7-17-17dea9` to `0.11.7-29-f2e220`. https://github.com/com-lihaoyi/mill/compare/17dea9...f2e220

Based on https://dotnet.social/@fornever/112560707798240443, which points to https://fornever.me/en/posts/2024-06-05.scala-jpackage-publishing.html, I tried to implement a generic `jpackage` target that can produce self-contained executables for any `JavaModule` (or `ScalaModule`). This is a WIP PR...

Merged as part of https://github.com/com-lihaoyi/mill/pull/4038

The test covering this task: ```scala def sometimesFailingWithException(fail: Boolean): Task[String] = T.task { if (!fail) "Success" else T.fail("Failure") } ``` fails with ``` X mill.eval.SeqTaskTests.sometimeFailingWithException.failure 2ms java.lang.AssertionError: assertion failed: ==>...

> Instead of converting to a `Result.Failure` you could add a rule to pretty print the error message as I did in the other PR for `Result.Exception(Result.Failure)` but for `Result.Exception(ResultFailureException)`...

This PR is still in draft state, since there is one open issue: https://github.com/com-lihaoyi/mill/pull/3422#issuecomment-2315741498. Has an fix or an idea?