Skip to content
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

runIvyDeps should be transitive for consistency with Maven resolution #3761

Closed
lefou opened this issue Oct 17, 2024 Discussed in #3722 · 1 comment · Fixed by #3774
Closed

runIvyDeps should be transitive for consistency with Maven resolution #3761

lefou opened this issue Oct 17, 2024 Discussed in #3722 · 1 comment · Fixed by #3774
Milestone

Comments

@lefou
Copy link
Member

lefou commented Oct 17, 2024

Discussed in #3722

Originally posted by megri October 12, 2024
Let's say we have the modules A <- B <- C where <- denotes a "depends on" relationship

// running with mill version 0.11.12
import mill._, mill.scalalib._

trait BaseModule extends ScalaModule {
  def scalaVersion = "3.5.1"
}

object C extends BaseModule {
  def ivyDeps = Agg(
    ivy"org.slf4j:slf4j-api:2.0.16"
  )
}

object B extends BaseModule {
  def moduleDeps = Seq(C)

  def runIvyDeps = Agg(
    ivy"ch.qos.logback:logback-classic:1.5.10"
  )
}

object A extends BaseModule {
  def moduleDeps = Seq(B)
}

So C introduces slf4j and B a logging implementation. mill A.ivyDepsTree --withRuntime shows

[build.sc] [54/59] compile 
[info] compiling 1 Scala source to /Users/martin/dev/mill-deps-test/out/mill-build/compile.dest/classes ...
[info] done compiling
[26/26] A.ivyDepsTree 
├─ org.scala-lang:scala3-library_3:3.5.1
│  └─ org.scala-lang:scala-library:2.13.14
└─ org.slf4j:slf4j-api:2.0.16

While the example may seem a little contrived—why not define the runtime dependency in the A module?—this has consequences with for instance assemblies. At work we have a project of several Spark applications (as separate modules) that are packaged into one single assembly for easy shipping. These modules have different but non-conflicting [runtime] dependencies, and the assembly won't collect the runtime parts without overriding for instance transitiveIvyDeps (which solves one level of transitivity—it has to be overridden in all modules to include "deep" runIvyDeps.)

Aside from backwards compatibility, would making runIvyDeps transitive be an issue?

@lefou lefou changed the title runIvyDeps are currently not transitive. Should they be? runIvyDeps should be transitive for consistency with Maven resolution Oct 17, 2024
@megri
Copy link
Contributor

megri commented Oct 17, 2024

I think I can implement this, but I'd like us to map out which parts need to be touched and expected outcomes.
Today we basically have no transitivity and the runtime dep doesn't end up in packaged artefacts. This change would make it so that

  • modules inherit runtime dependencies through something akin to transitiveIvyDeps
  • runtime deps are included in packaged jars and Pom-files.

What else?

@lefou lefou added this to the 0.12.0 milestone Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants