Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix incremental compilation when a Scala project depends on a Java project #414

Merged
merged 4 commits into from
Aug 25, 2018

Conversation

smarter
Copy link
Collaborator

@smarter smarter commented Aug 22, 2018

This PR depends on #411


Before this PR, 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.

@smarter
Copy link
Collaborator Author

smarter commented Aug 22, 2018

@lihaoyi Please please don't use "Squash and merge" when merging this :).

@lihaoyi
Copy link
Member

lihaoyi commented Aug 22, 2018

looks good to me i guess, feel free to merge whenever

This is mainly to get com-lihaoyi/Ammonite#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.
Starting with the next commit, it will be used in Java-only projects
too, so the name is misleading.
@smarter smarter force-pushed the fix-java-inc branch 2 times, most recently from 843c17b to 17792b4 Compare August 23, 2018 08:58
…oject

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.
@smarter smarter merged commit 146d58b into com-lihaoyi:master Aug 25, 2018
@lefou lefou added this to the 0.2.7 milestone Apr 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants