[run/compile]IvyDeps shall be transitive to the nested test module like ivyDeps

[b-gyula]

Like in gradle: If some dependency needed for compile the artifact (like a macro library), it's most probably needed for compile the tests as well.
The same applies for run: when an artifact needs a dependency to be able to run, that is certainly needed to run a test also. E.g. If a DB driver needed for an app to run, then test won't be able to run it without it for sure.

[lefou]

I definitely disagree for compileIvyDeps. It's their exact purpose to be compile-time only and not transitive.

I personally like the non-transitive behavior of runIvyDeps in Mill very much, as it gives more power in rather large projects. Working this way is much more pleasant (to me) than was all that fiddling with excludes in other build tools.

[lefou]

Interesting. I guess I'd like to try to test your project, but can't promise anything, as my time is fairly limited.

[lefou]

Can you post the concrete mill commands which fail? Also, are there any other requirements besides checking out and running Mill?

[lefou]

Hm, this whole thread was initially about transitivity of ivyDeps. But from a quick glance at your linked PR (ArtOfIllusion/ArtOfIllusion#275) you're using unmanagedClasspath for almost all dependencies. Please beware, that unmanagedClasspath is not transitive. I added a comment to your PR.

[lefou]

It's also very common when working with non-public jars, to provision them locally into the local Ivy or Maven repository and then just use them via ivyDeps. mill.scalalib.publish.LocalIvyPublisher or mill.scalalib.publish.LocalM2Publisher is your friend. It's in most cases ok to just push empty doc and source jars, if you don't have them.

[Sailsman63]

Yeah, sorry that I've sort of strayed from the original topic. I thought they were thematically the same when I started.

I will look into the local publisher options - I'm aware that unmanaged dependencies are not ideal, but I kind of need to get the build working before I can think too hard about upgrading dependencies. (Our existing legacy ant build is entirely unmanaged dependencies, and one of the motivators in moving to something else is ease of transitioning to managed dependencies. This build is already an improvement in that regard)