Open lefou opened 1 year ago
As an alternative, we could embed the sources into the mill-launcher
. This will make the jar file larger, but will always provide the correct sources files for lookup.
We should consider removing mill-launcher
from the classpath and having a smaller explicitly-defined classpath. We don't want everything that Mill uses internally to be on the classpath and accessible from user build.sc
files.
Things like OS-Lib, uPickle, Requests-Scala, etc. probably need to be there, but we don't want random things like org.ow2.asm
or com.kohlschutter.junixsocket
or org.apache.ant
to end up there for users to use unless they explicitly import it
I agree. Then, we probably just want to define a minimal classpath via ivyDeps
.
We should try to embed these needed jars as resources in the mill-launcher, so we can create a minimal local ivy repository from it and use it for bootstrapping, so we don't need to download anything for the minimal build.sc
.
Currently, we use the Mill launcher jar to compile the Mill project. To do that, we add it to the
unmanagedClasspath
of theMillBUildModule
. Technically, this is correct. But in comparison with dependencies defined viaivyDeps
we loose some semantics we'd like to keep. For example, when editing the build sources files, we don't have properly attached sources, as there is no metadata to use to get the sources jar on demand.Instead we could define the dependency under
ivyDeps
. There are some issues to that approach, too:mill-launcher
To overcome all of those issues, we could intercept the
ivyDeps
resolution of the binarymill-launcher
and return the already present jar.