-
-
Notifications
You must be signed in to change notification settings - Fork 358
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
Kill mill.modules package #2513
Conversation
f8230c1
to
43f86cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but we need some @deprecated
type aliases and forwarder objects to keep source compatibility for a while. Migration and cross compilation is otherwise a pita and especially, when not the whole ecosystem is migrated, it's less attractive to try something out if there is no easy going back.
Added backwards compat forwarders. Needed to put them in |
Ticks off #1826 (comment)
mill.modules
is a very confusing name that I came up with very early in Mill's development. It misleadingly has nothing to do withmill.Module
, and is just a grab bag of helpers. This PR moves them to the JVM packages which are most related to their functionalityWe basically move the following files:
mill.modules.Assembly
->mill.scalalib.Assembly
mill.modules.Util
->mill.util.Util
mill.modules.Jvm
->mill.util.Jvm
mill.modules.CoursierSupport
->mill.util.CoursierSupport
There is probably further cleanup and re-organization we can do here. Currently,
Util
andJvm
are pretty tightly coupled together, withVisualizeModule
living inmain
stopping us from moving them all toscalalib
. An alternative is to moveAssembly
tomill.util
, so at leastcreateJar
andcreateAssembly
can live in the same package rather than being split acrossmill.{util,scalalib}
.But for now, just breaking up
mill.modules
should already be a step forward, and further cleanups can come in follow up PRs