[Question] Does Coursier 2.1.17 bring anything that we could use in this plugin?

[gaeljw]

Not an issue, rather a discussion thread

I've noticed the release of SBT 1.10.6 which mention some improvements regarding BOMs in Coursier.

However I'm absolutely confused/ignorant as whether there's anything that can either be used by this plugin or maybe even removes the need for this plugin?

---

From SBT 1.10.6 by @eed3si9n and Coursier 2.1.17 by @alexarchambault release notes:

This release changes the way "BOMs" or "dependency management" are handled during resolution, and allows users to add BOMs to a resolution. This changes the way versions are picked when BOMs or dependency management are involved, which has an impact on the resolution of libraries from many JVM ecosystems, such as Apache Spark, Springboot, Quarkus, etc. These changes were added in 3097 and 3143, mainly motivated by Mill's needs.

---

Does someone know and/or could clarify how this relates to what this plugin do?

[eed3si9n]

Does someone know and/or could clarify how this relates to what this plugin do?

I can try.

So we're all on the same page, when we say bill-of-materials (BOM), the canonical reference is https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs.

Imports are most effective when used for defining a "library" of related artifacts that are generally part of a multiproject build. It is fairly common for one project to use one or more artifacts from these libraries. However, it has sometimes been difficult to keep the versions in the project using the artifacts in synch with the versions distributed in the library. The pattern below illustrates how a "bill of materials" (BOM) can be created for use by other projects.

In other words, it refers to a usage pattern / feature in Maven that allows packages to share version numbers, both for direct and transitive dependencies.

sbt users typically try to do this via project/Dependencies.scala. What this plugin offers, I think is a consumption of an existing BOM, so an sbt build can integrate with existing BOM ecosystem. This is great since sbt currently lacks that feature.

What happened in Coursier 2.1.17 / sbt 1.10.6, as far as I know, is that if an existing Java library dependency graph includes BOM, Coursier would do a better job emulation the dependency resolution semantics of Maven, so the transitive dependency would use BOM-specified version number. sbt 1.10.6 currently does not offer the capability for build users to integrate with BOMs.

I have just send a proposal scalacenter/advisoryboard#168, which outlines step towards creating and integrating with BOMs. This may or may not happen, depending on the community interest and resources. If people find the proposal interesting or want to join the effort, please comment on it.

[gaeljw]

Thanks a lot @eed3si9n. Definitely clearer in my mind now :)

I did see your proposal scalacenter/advisoryboard#168. This is the one that actually made me think to ask this question here 😅

[alexarchambault]

To add to @eed3si9n's answer, I think there is some overlap. Basically, now, users can resolve dependencies in coursier while passing a BOM (or several…) whose versions should be used. From the coursier command-line, one can pass --bom org:name:ver to fetch a BOM and force its versions on transitive dependencies being resolved.

I'm in the midst of adding BOM support in Mill based on these new coursier capabilities, in com-lihaoyi/mill#3924 (and upcoming subsequent PRs…). It seems the plugin here tries to emulate that in sbt. So with these new coursier capabilities, sbt could gain support for BOMs too, although this needs a bit of work (defining new keys to accept BOMs, maybe offering a way for users to define and publish their own, …)