cc @eed3si9n who dived a quite a bit in dependency resolver intricacies and @lefou who manifested interest for BOM support in #1390. Also cc-ing @lihaoyi and @adpi2 given this should impact both Mill and sbt, and @jin for rules_jvm_external

I haven't reviewed the code, but the PR description looks like exactly what we'd want, since it makes Coursier resolutions behave the same as Maven or Gradle or other tools

AFAIK, Mill doesn't have an equivalent target.

I'm probably going to have a look at this next: adding an equivalent to dependencyOverrides in Mill, and make sure its values are added to published POM files (and checking that these overrides are taken into account when coursier pulls these)

In sbt for example, the values of dependencyOverrides are equivalent to BOM values. As a consequence, these can be published.

I think this is mostly true, but there is a small details of Maven dependency quirk, which we might have to be aware: I think Maven prioritizes direct dependency over dependencyManagement.

I think that matches my perception. Local dependency declarations override management overrides parent poms. There are a lot of precedence rules in Maven with regard to dependency management. I think the following page list some or all (?) of them:

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-management

It also mentions a new packaging type bom (since Maven 4.0 and the POM Model 4.1.0).

In case Coursier will follow the Maven semantics, we should name the new task in Mill rather dependencyManagement than dependencyOverrides, as "overrides" implies a simple rule. Too simple.

cc @shs96c for rules_jvm_external's BOM support.

We currently ask folks who need BOMs to switch to a different Aether based resolver (https://github.com/bazel-contrib/rules_jvm_external?tab=readme-ov-file#experimental-support-for-maven-bom-files), so it would definitely be nice to have this.

We will be happy to try out a build of coursier with our tests (https://github.com/bazel-contrib/rules_jvm_external/blob/3ea96498725cb21e3ac18490cc3f3b75db2259ca/MODULE.bazel#L618, https://github.com/bazel-contrib/rules_jvm_external/blob/master/MODULE.bazel#L432)

What needs to be done in Mill:

• Decide, how we do declare managed dependencies? We should add a new task to CoursierModule. We need to agree on a good name. The type should be T[Seq[Dep]].
• Decide, how we do import a BOM dependencies in import-scope? In Mill dependencies don't have scopes, but we manage multiple scope-like dependency sets: ivyDeps ~= compile-scope, runIvyDeps ~= runtime-scope, compileIvyDeps ~= provided-scope. (To import BOMs via ivyDeps, we need to find out, if Maven makes a distinction between these scopes and if there are any situations, where mixing compile and import scope for BOM management is problematic.) We better add a new task to import those BOMs. The task name might match the other new task name but add a suffix like Includes or Imports. The type is also T[Seq[Dep]].
• How can we produce BOM artifacts? I think this should already work by changing the PublishModule.pomPackagingType to Pom. We just need to generate the <dependencyManagement> node in the pom task. Don't know what the equivalent to ivy is, if there is any.

@lefou Thanks for all these details. Let's discuss these Mill-specific points in an upcoming Mill issue or early PR that I'll open about this

I think this is mostly true, but there is a small details of Maven dependency quirk, which we might have to be aware: I think Maven prioritizes direct dependency over dependencyManagement.

@eed3si9n Thanks for mentioning this. I'm well aware of this point, coursier does follow this rule when using dependency management. I didn't mention it to keep my explanations simple, but this will have to be taken into account when generating POM files: in sbt, if dependencyOverrides versions take over libraryDependencies versions, the generated POM should only have the former versions, not the latter, in order for dependency resolution to use the same version

Going to merge this, with the feature enabled by default. I should mention it in the next release notes, but those changes can be easily disabled, and you might want to allow sbt / Mill / rules_jvm_external users to do so.

From the API, it can be disabled via the ResolutionParams, like

Resolve()
  .mapResolutionParams(_.withEnableDependencyOverrides(Some(false)))
// or
Fetch()
  .mapResolutionParams(_.withEnableDependencyOverrides(Some(false)))

On the CLI, --enable-dependency-overrides=false allows to disable it.

For scala-{library,reflect,compiler}, most of the time, these versions are just forced during dependency resolution. We might want to manage those via a dependency management section or even a BOM now 🤔 That BOM could even be managed by the Scala compiler team itself, especially for Scala 3, where the scala-library version (2.13 scala-library that Scala 3 pulls) cannot be mapped directly from the Scala 3 version.

cc @Gedochao, as Scala CLI resolves dependencies and publishes them too. IIRC, Scala CLI uses coursier via coursier-interface. Options to disable the feature here should be added to it too, to allow Scala CLI to disable it too. Maybe some BOM support could be added to Scala CLI too (see discussion above)