-
-
Notifications
You must be signed in to change notification settings - Fork 371
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
play-contrib: Fixed classloading of worker module and cleanups #1330
Conversation
private var routeCompilerInstanceCache = Option.empty[(Long, mill.playlib.api.RouteCompilerWorkerApi)] | ||
|
||
private def bridge(toolsClasspath: Agg[os.Path]) | ||
protected def bridge(toolsClasspath: Agg[os.Path]) | ||
(implicit ctx: Ctx) = { |
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.
The alignment went a bit off here.
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.
Fixed.
val workerKey = "MILL_CONTRIB_PLAYLIB_ROUTECOMPILER_WORKER_" + playMinorVersion().replace(".", "_") | ||
|
||
mill.modules.Util.millProjectModule( | ||
workerKey, | ||
s"mill-contrib-playlib-worker-${playMinorVersion()}", | ||
repositoriesTask(), | ||
resolveFilter = _.toString.contains("mill-contrib-playlib-worker"), | ||
// resolveFilter = _.toString.contains("mill-contrib-playlib-worker"), |
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.
Shouldn't you delete this line?
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.
Of course. Fixed.
As a person that doesn't know a lot about Mill internals (but a bit more than the average user), I struggled a lot to find which one of you changes actually fixed the classloader bug in the diff --git a/contrib/playlib/src/mill/playlib/RouteCompilerWorkerApi.scala b/contrib/playlib/src/mill/playlib/RouteCompilerWorkerApi.scala
index 3b632a68..5b2cfe06 100644
--- a/contrib/playlib/src/mill/playlib/RouteCompilerWorkerApi.scala
+++ b/contrib/playlib/src/mill/playlib/RouteCompilerWorkerApi.scala
@@ -21,6 +21,7 @@ private[playlib] class RouteCompilerWorker {
val cl = mill.api.ClassLoader.create(
toolsClassPath,
null,
+ sharedLoader = getClass().getClassLoader(),
sharedPrefixes = Seq("mill.playlib.api.")
)
val bridge = cl
diff --git a/contrib/playlib/src/mill/playlib/RouterModule.scala b/contrib/playlib/src/mill/playlib/RouterModule.scala
index 4c0efd6b..4be78bf8 100644
--- a/contrib/playlib/src/mill/playlib/RouterModule.scala
+++ b/contrib/playlib/src/mill/playlib/RouterModule.scala
@@ -79,7 +79,6 @@ trait RouterModule extends ScalaModule with Version {
workerKey,
s"mill-contrib-playlib-worker-${playMinorVersion()}",
repositoriesTask(),
- resolveFilter = _.toString.contains("mill-contrib-playlib-worker"),
artifactSuffix = playMinorVersion() match {
case "2.6" => "_2.12"
case _ => "_2.13" Can we have a PR with just this diff to solve the bug first? |
Yeah, makes sense. |
Fixed dependency resolution of worker classpath. The collected classpath of the worker module was limited to only use the worker module. But this misses all transitive dependencies of the worker. This is probably because of older limitiations in mill builds, which also included the mill API itself. Now, mill uses `compileModuleDeps` for the mill API and we have clean and usable transitive module and worker classpaths. Fixed use of mills utility classloader by settings the correct parent classloader. Using the classloader of the module as parent makes the shared API modules (which need to be already loaded by the mill build) visible. The perviously used default was using the classloader which loaded the mill build (and the ammonite script), which misses the play API module (loaded via `$ivy` import).
I amended my commit and will move other improvments to a new PR. |
I'm going to do it! |
Already done. :-D |
Yeah, was just editing the comment :D You're a machine! |
I confirm it works! |
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.
LGTM! 👍
That's because we don't use mills (ammonites) loading mechanism but just run the tests in the test classloader. This is a limitation but speeds up mills integration tests a lot. But it's one of the reasons I prefer mill plugins in their own repos and integration test them with https://github.com/lefou/mill-integrationtest plugin (shameless plug). That's slower but catches such kind of problems. Also, you can better test compatibility to different mill versions. |
Fixed use of mills utility classloader by settings the correct parent classloader.
Using the classloader of the module as parent makes the shared API modules (which need to be already loaded by the mill build) visible.
The previously used default was using the classloader which loaded the mill build (and the ammonite script), which misses the play API module (loaded via
$ivy
import).Fixed dependency resolution of worker classpath.
The collected classpath of the worker module was limited to only use the worker module.
But this misses all transitive dependencies of the worker.
This is probably because of older limitiations in mill builds, which also included the mill API itself.
Now, mill uses
compileModuleDeps
for the mill API and we have clean and usable transitive module and worker classpaths.