Mill after 0.1.7-8-b913c6 cannot build itself properly

[robby-phd]

Stumbled upon this when working on #262 so documenting it as an issue: changes between 0.1.7-8-b913c6 and 0.1.7-19-680364 cause mill not to be able to build itself properly; the resulting mill gives the following error trace when compiling itself:

mill.scalalib.ScalaWorkerModule.worker java.lang.NoClassDefFoundError: sbt/internal/inc/CompileFailed
    java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
    java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3110)
    java.base/java.lang.Class.getConstructor0(Class.java:3315)
    java.base/java.lang.Class.getConstructor(Class.java:2108)
    mill.scalalib.ScalaWorkerModule.$anonfun$worker$2(ScalaWorkerApi.scala:43)

See the following appveyor and travis runs.

[robby-phd]

@lihaoyi and @shengc, seems like #254's a4713c3 is the culprit.

I made test-mill-release.sh to build mill release 2 times recursively (instead of only 1 time) before running the test, resulting in the above error during compilation (see travis # 897); after reverting a4713c3, the build no longer has the issue (see travis # 898; compilation passed but tests still failed; sometimes I got those errors on my local machine, no idea why, but that is not the focus here).

[lihaoyi]

@robby-phd feel free to revert it if that fixes bootstrapping

[lihaoyi]

@robby-phd #254 has been reverted

[lihaoyi]

I suspect https://github.com/lihaoyi/mill/pull/254/files#diff-30112550a1f0d3b2fb7d9d59c21bf5aaL44 is the mistake in #254

[robby-phd]

I added a ci bootstrapping test in f972d71 to help avoid against this kind of issues in the future, e.g., if @shengc (or someone else) wants to revive #254.

[shengc]

@lihaoyi is this more of a revelation of a problem ... ? if dependencies carried for mill build does not have any "exclusion" sort of logic, a4713c3 should have no effect.

[robby-phd]

@shengc It is a possibility; I'm not familiar with that part of mill codebase so @lihaoyi can comment on this more authoritatively. If it is indeed there is an underlying issue, #254 can be revived once that issue is fixed. (I'm actually using the exclusion feature in some of my projects, which is handy.) For now, I think mill should always be able to bootstrap itself so we have some confidence when making changes and accepting pull requests.

[shengc]

@robby-phd I have found the problem and opened PR #274