-
-
Notifications
You must be signed in to change notification settings - Fork 364
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
Add ability to select Java versions on a per-module basis (1000USD bounty) #3480
Comments
See prior discussions in the related issue |
lihaoyi
changed the title
Add ability to select Java versions on a per-module basis
Add ability to select Java versions on a per-module basis (1500USD bounty)
Sep 15, 2024
lihaoyi
changed the title
Add ability to select Java versions on a per-module basis (1500USD bounty)
Add ability to select Java versions on a per-module basis (1000USD bounty)
Sep 15, 2024
Closed
lihaoyi
added a commit
that referenced
this issue
Nov 20, 2024
Fixes #3480. Changes: - adds `coursier-jvm` as a dependency to the `util` module, this library is for fetching JVMs using coursier and the coursier [jvm-index](https://github.com/coursier/jvm-index) - add a `def javaHome: Task[Option[PathRef]]` task to `ZincWorkerModule`. This defaults to `None`, which is the existing behavior of using mill's java home. - Users who want to use a custom JVM need to define a custom `ZincWorkerModule` and override `def jvmId`, optionally `def jvmIndexVersion` - updates the `mockito` and `commons-io` examples to use the new configuration options. Now these examples should run even when mill itself is not running on java 11. - This also required adding `-encoding utf-8` to the projects' javac options. - update the `run` and `test` tasks to use the `zincWorker`'s java home if a different one specified Notes: * `JavaModule#compile` forks a new JVM for each compilation to support custom JVM versions, and `ScalaModule#compile` does not support custom JVM versions at all. This would require a deeper refactoring of `ZincWorkerModule` to fix * --------- Co-authored-by: Li Haoyi <haoyi.sg@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From the maintainer Li Haoyi: I'm putting a 1000USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
Currently Mill just uses the global Java for everything, which is not ideal: many projects have different parts that require different Java versions. e.g. Mockito has a submodule that requires Java 21 https://github.com/mockito/mockito/tree/main/subprojects/java21-test, and of course Mill itself has different parts targetting different versions (e.g. half our thirdparty tests run on 11, half run on 17). Currently we get by with separate jobs on Github Actions, but that's clunky and annoying to work with since it doesn't reproduce locally.
Ideally we should be able to specify Java versions on a per-module basis, which Mill will download and cache as necessary to run those specific modules. As JVM downloads can be expensive, it is probably worth caching things globally (probably the same place we cache the Mill assembly jar?) rather than caching them in the
out/
folder of each projectGradle has something like this (https://docs.gradle.org/current/userguide/building_java_projects.html#sec:java_cross_compilation), and it feels like it would be very useful for Mill as well
The text was updated successfully, but these errors were encountered: