From 146d58bc5d98da1d142758f974d4d5de6f5948bf Mon Sep 17 00:00:00 2001 From: Guillaume Martres Date: Sat, 25 Aug 2018 18:28:59 +0900 Subject: Fix incremental compilation when a Scala project depends on a Java project (#414) * Upgrade ammonite to 1.1.2-30-53edc31 This is mainly to get https://github.com/lihaoyi/Ammonite/pull/851 which should reduce the amount of unnecessary work done by incremental compilation in the Mill build. This requires some code changes since this means we now depend on a more recent version of coursier, as a side-effect this means that we do not depend on scalaz anymore. Also use the same ammonite version in the Mill build and in ScalaModule#ammoniteReplClasspath. Also remove an incorrect dependency in the caffeine integration test. This was always wrong but did not start failing until this commit, probably due to dependencies appearing in a different order on the classpath. * Rename ScalaWorker to ZincWorker Starting with the next commit, it will be used in Java-only projects too, so the name is misleading. * Upgrade to Zinc 1.2.1 * Fix incremental compilation when a Scala project depends on a Java project Before this commit, JavaModule#compile simply called javac unconditionally, thus generating new classfiles every time. But if a Scala project depends on a Java project, this will throw off the incremental compilation algorithm which will unnecessarily recompile files. To avoid this we now use Zinc to compile Java projects too (as a bonus this means that Java compilation becomes incremental). This required some refactoring in ZincWorkerImpl to be able to compile stuff without having to pass Scala-specific options. The issue solved by this commit could be reproduced by running in the Mill repository: $ mill main.compile $ mill -i @ main.compile() and observing that before this commit, the `main.compile()` call ended up recompiling code. --- docs/pages/2 - Configuring Mill.md | 6 +++--- docs/pages/5 - Modules.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/pages') diff --git a/docs/pages/2 - Configuring Mill.md b/docs/pages/2 - Configuring Mill.md index 7db19833..989272dd 100644 --- a/docs/pages/2 - Configuring Mill.md +++ b/docs/pages/2 - Configuring Mill.md @@ -72,20 +72,20 @@ def repositories = super.repositories ++ Seq( ``` To add custom resolvers to the initial bootstrap of the build, you can create a -custom `ScalaWorkerModule`, and override the `scalaWorker` method in your +custom `ZincWorkerModule`, and override the `zincWorker` method in your `ScalaModule` by pointing it to that custom object: ```scala import coursier.maven.MavenRepository -object CustomScalaWorkerModule extends ScalaWorkerModule { +object CustomZincWorkerModule extends ZincWorkerModule { def repositories() = super.repositories ++ Seq( MavenRepository("https://oss.sonatype.org/content/repositories/releases") ) } object YourBuild extends ScalaModule { - def scalaWorker = CustomScalaWorkerModule + def zincWorker = CustomZincWorkerModule // ... rest of your build definitions } ``` diff --git a/docs/pages/5 - Modules.md b/docs/pages/5 - Modules.md index 2c13a3e9..fa6260f3 100644 --- a/docs/pages/5 - Modules.md +++ b/docs/pages/5 - Modules.md @@ -152,7 +152,7 @@ mill foo.Bar/qux `ExternalModule`s are useful for someone providing a library for use with Mill that is shared by the entire build: for example, -`mill.scalalib.ScalaWorkerApi/scalaWorker` provides a shared Scala compilation +`mill.scalalib.ZincWorkerApi/zincWorker` provides a shared Scala compilation service & cache that is shared between all `ScalaModule`s, and `mill.scalalib.GenIdea/idea` lets you generate IntelliJ projects without needing to define your own `T.command` in your `build.sc` file -- cgit v1.2.3